ShotGrid REST API v5 and v6 concurrent requests during application migration

Short answer

Addressing v5 and v6 concurrently from one client is a documented property of the versioning surface — via URL path or the X-Api-Version header. Whether that dual-version traffic is supported for production is a separate question from whether it is technically possible, and it is the one you should not assume. Treat concurrent production traffic as technically feasible but contractually unverified until Autodesk confirms it for your account and plan.

What is reasonably firm vs. what needs review

Reasonably firm

• Version selection via URL path and header is part of the documented surface.
• OAuth2 access tokens are typically scoped to the environment or account rather than to a single major version, so one token usually authenticates both — verify, do not assume.
• There is no server-side cut-over; the switch is client-orchestrated.

Marked for review

• Rate-limit accounting scope. Your brief states limits are applied per API version; other summaries describe account- or key-level enforcement. These produce different capacity math and cannot be resolved without current documentation. Verify empirically.
• Payload and schema parity for the specific entities you touch.
• Whether dual-version production load is explicitly permitted.

Rate limits when both versions are in flight

Two models are plausible:

• Per-version buckets: v5 and v6 draw from separate quotas; dual traffic roughly doubles your usable ceiling, but each bucket can still return 429 independently.
• Shared bucket: both versions consume one quota; a migration doubles request volume against the same ceiling and you hit 429 sooner.

Do not size the migration on either model until you measure. During the window, budget as if the shared model is true — it is the conservative case — and keep retry with backoff and jitter in place. Honor Retry-After when present.

Decision criteria for the switch

1. Anchor to a signal, not a date. Deprecation windows move. Gate the switch on a monitored official notice plus your own readiness, not a calendar entry.
2. Parity gate. Diff representative responses for the entities you use; confirm pagination, filtering, and error semantics.
3. Rollback gate. The version must be changeable by configuration or flag without a redeploy, and revertible in one step.
4. Observability gate. Per-version request counts, error rates, latency, and 429 counts must be visible before you shift traffic.
5. Shift gradually. A canary or percentage rollout beats a single cut-over.

Verification you can run

# Same token against both versions (illustrative; confirm current endpoints)
curl -sS -o /dev/null -w '%{http_code}\n' \
  -H "Authorization: Bearer $TOKEN" \
  -H "X-Api-Version: v5" \
  "$BASE/v5/entity/human_user/1"

curl -sS -o /dev/null -w '%{http_code}\n' \
  -H "Authorization: Bearer $TOKEN" \
  -H "X-Api-Version: v6" \
  "$BASE/v6/entity/human_user/1"

Then run a controlled burst against both and count 429s and any rate-limit headers to infer bucket scope. Compare payloads for one entity to find breaking changes.

One detail that changes the recommendation

Can your client choose the version per request, or only per process or base URL? If it is per request, you can canary inside one deployment and the plan above applies directly. If it is per process, you need two deployments behind a router or flag, and the rollback and observability gates become the binding constraints.