Skip to main content
The Passthrough API uses the same API keys as the rest of SportriX. A key is accepted here when it is active and carries all three of:
  1. the odds scope,
  2. a grant for the sportsbook you are calling — pinnacle for /v1/pinnacle, and
  3. a grant for the sport you are asking about — see Per-sport grants below.
All conditions are required. A key with the odds scope but no pinnacle grant is rejected, a pinnacle key without the odds scope is rejected, and a key that holds odds and pinnacle but not the sport in question is rejected on any request that names that sport.
odds is a single scope covering both prematch and live prices. There is no separate live-odds permission to request.

​
Passing your key

​
REST — X-API-Key header

​
WebSocket — header or key parameter

The key is checked during the handshake, before the connection is upgraded. Server-side clients should send the header:
Browsers cannot set headers on a WebSocket handshake, so the key may also be passed as a query parameter:
The key parameter is accepted on REST endpoints too, but the header is preferred — query strings end up in proxy logs and browser history.
A key in a query parameter is a key in your logs. Use ?key= only where a header is genuinely impossible, and prefer proxying browser traffic through your own backend.
When both are present, the header wins.

​
Sportsbook grants

Each sportsbook is passed through by its own stack under its own path prefix, and each is granted independently on your key. Today that is: A key granted one book cannot read another’s data.

​
Per-sport grants

On top of the sportsbook grant, a key carries an allowlist of sports within that sportsbook. Access is deny by default — a newly issued key with no sport grants sees an empty book, even if it holds odds and pinnacle.
Sport ids in this allowlist are the sportsbook’s own ids, not the SportriX fixture catalog ids. On Pinnacle, for example, 12 is E Sports, 3 is Baseball, and 29 is Soccer. The two id spaces are unrelated — matching them by number is coincidence, not correspondence. Use ids from GET /sports, never from the SportriX fixture API.

​
How grants are enforced

The allowlist affects both REST and WebSocket. The rule is consistent: list endpoints filter, explicit sport references reject. The reason lists filter rather than reject is that the honest answer to “what can I see?” is the granted subset. The reason an explicit ?sport= or match id rejects with 403 is that silence would be indistinguishable from a bug — the set of sports a sportsbook offers is public, so refusing loudly is cheaper to support and leaks nothing.

​
A worked example

A pinnacle key granted E Sports (12) and Soccer (29), but not Baseball (3):
To have specific sports added to your key, contact SportriX support with the sportsbook and the sport ids from GET /sports.

​
Authentication errors

Every failure is a JSON body with an error field:
A 503 is about the authentication backend, not your key. Treat it as transient and retry — do not disable the key or alert on it as a permission problem.

​
Unauthenticated endpoints

Two endpoints answer without a key, deliberately, so that a liveness probe does not need a credential: To know whether the data is live rather than just the process, read the feed_healthy flag on your WebSocket heartbeat.

​
Key propagation

Keys are managed centrally and mirrored to each sportsbook stack, which caches the result briefly. A newly issued key, a scope change, or a deactivation takes effect within roughly 15 seconds — not instantly.
To have the odds scope, a sportsbook grant, or specific sport grants added to your key, contact SportriX support. No key rotation is needed.