Common Authentication / Integration Issues
400 - Bad Request
A 400 response to any of our APIs will be returned for one of the following reasons:
If any of the required query parameters are missing (auth, timestamp, operator ID)
If any of the required parameters are invalid (e.g. misspelt - "aut" instead of "auth")
401 - Unauthorized - Invalid Timestamp
A 401 response can be returned for a number of reasons. The first of these is that the timestamp parameter is invalid. A timestamp can be invalid for the following reasons:
The timestamp parameter is defined in seconds and not milliseconds. e.g. 1581099492 (seconds) vs 1581099493969 (milliseconds).
If the timestamp parameter is not within 30 seconds of the time that the request was made.
The timestamp that is hashed in the authentication token does not match the timestamp from the request.
If you are unsure what time your timestamp parameter translates to, you can use https://www.epochconverter.com/ to convert timestamp to human date, and vice versa.
401 - Unauthorized - Invalid Authentication Token
A 401 can also be returned if the authentication token is invalid. An authentication token can be invalid for the following reasons:
The wrong Operator ID is hashed into the auth token
The wrong API Secret is hashed into the auth token
The IP address hashed into the auth token does not match
For 3. there are two main causes of an IP mismatch:
IP Mismatch 1: Client requests from networks with multiple IPs
The most common cause of an IP mismatch is that the client that is making the request to the API is on a network with multiple IPs. When this happens, there can be one IP address hashed into the authentication token, but the request to the API can be made from the other IP address.
We most often see this issue in office networks of our customers. If you are seeing frequent 401 errors from a particular office network, we recommend reaching out to your office IT/Network Infrastructure team to see if they are able to resolve the issue and ensure all requests to our APIs come from one IP address.
Currently the Streaming API only supports requests over IPv4. We would therefore expect all tokens to include an IPv4 IP Address. The user's IPv4 address can be confirmed via a service that provides the user's public IP addresses from the frontend, or with a call to an API on the backend that is only served over IPv4.
IP Mismatch 2: Server IP hashed into auth token
This is a common integration issue. If the IP address of the server that is generating the authentication token is hashed into the authentication token, this will not match the IP address of the client IP that makes the request, and will result in a 401.
It is imperative that all calls to the Streaming API are made client side - this is so that we can check the client's IP and ensure that we are correctly applying any geo-restrictions to the content.
403 - Forbidden
A 403 response is returned to our Streaming API when an event is geo-blocked.
In order to correctly geo-block events, we check the IP address from the request to our Streaming API against an IP database from Maxmind.
If you think that an event is incorrectly being geo-blocked, we recommend heading to this link: https://www.maxmind.com/en/geoip-demo and inputting the IP address from where the request was made.
If this matches where you expect in the Maxmind database - please reach out to our support team, who will be happy to check the geo-restrictions on that event.
If the IP address does not match where you expect in the Maxmind database - please reach out to our support team, who will endeavour to contact Maxmind to get this rectified.
404 - Not Found
A 404 is returned from our Streaming API if an event has been deleted.
Events can be deleted for a number of reasons - Tennis matches can be moved to non-streaming courts at the last minute, football matches can fall foul of weather. In the event an event is deleted from the platform, we will send out a notification informing customers. However, if you are still unsure, or require more information, please reach out to our support team.
CORS Headers
The CORS header may not be working due to someone using OPTIONS instead of GET. We can confirm that we do not support OPTIONS requests to our streaming API. You should only make a GET request, without any additional headers to our streaming API.
You are not required to send any custom headers with the simple GET request to our streaming API, therefore, the browser will not need to make any preflight OPTIONS requests.
Please refer to the following documentation on how to make simple requests: https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#Simple_requests
Last updated
Was this helpful?
