Sport Line API — Authentication and Access
How API Access Works
To use Sport Line API, the client receives the following from the SportAPI manager:
- the sports line base URL;
- a personal API key;
- the available sports;
- the available languages;
- the access expiration date;
- the terms of the selected subscription package.
The API key is associated with the client’s subscription. The API uses it to verify the access period and the list of available sports and languages. If the requested data is not included in the subscription, the API will return an access error or omit that data from the response.
To obtain access, contact the SportAPI manager on Telegram.
The Package Header
Send your API key in the Package HTTP header with every request:
Package: YOUR_API_KEY
Request URL:
GET https://YOUR_API_DOMAIN/v1/menu/live/en
Request HTTP headers:
Package: YOUR_API_KEY
Accept: application/json
The YOUR_API_KEY value must be sent in the Package header, not in the URL.
The complete HTTP request looks like this:
GET /v1/menu/live/en HTTP/1.1
Host: YOUR_API_DOMAIN
Package: YOUR_API_KEY
Accept: application/json
Replace:
https://YOUR_API_DOMAINwith the base URL provided by the manager;YOUR_API_KEYwith your API key.
Do not send the key:
- in URL parameters;
- in the body of a GET request;
- in a file name;
- in error messages;
- in public documentation or examples.
cURL Example
You can use environment variables for local testing:
export SPORTAPI_BASE_URL='https://YOUR_API_DOMAIN'
export SPORTAPI_KEY='YOUR_API_KEY'
curl --request GET \
--url "$SPORTAPI_BASE_URL/v1/menu/live/en" \
--header "Package: $SPORTAPI_KEY"
Do not store an active key in the shell history of a shared computer.
Storing the Key Securely
Store the API key in your application’s protected configuration:
- an environment variable;
- hosting or CI/CD secrets;
- a secrets manager;
- server-side configuration that is not committed to the repository.
Do not hard-code an active key in the source code or commit a file containing the key to Git.
If sports data is used on a public website, requests to Sport Line API should be made through your backend. This prevents website visitors from seeing the personal key in their browsers.
If the key is accidentally exposed, contact SportAPI support to have it replaced.
Sport Restrictions
The key contains a list of available sports.
The supported sports and esports disciplines and their sport_id values are listed in
the SportAPI Sports Reference.
If a requested sportId is not included in the subscription, the API may deny access:
{
"error_code": 100,
"error_message": "Access denied"
}
Methods that return multiple sports build their responses according to the client’s access. Sports that are not included in the subscription may be omitted from the response.
Language Restrictions
The complete list of available languages and their codes is provided in the Sport Line API Language Reference.
The language code is included in the request path:
/v1/menu/live/ru
/v1/menu/live/en
The requested language must:
- be supported by Sport Line API;
- be included in the client’s subscription.
If the language exists but is not included in the key’s subscription, the API returns:
{
"error_code": 100,
"error_message": "The language is not available in your package."
}
If an unsupported language code is provided, the API may return:
{
"error_code": 100,
"error_message": "Invalid language"
}
Contact the SportAPI manager for the exact list of languages available to your key.
Key Status and Expiration
Access remains available while the key:
- exists in the system;
- has an active status;
- has not reached its expiration date;
- provides access to the requested data.
If the access period has ended or the key has been disabled, the API returns:
{
"error_code": 100,
"error_message": "Package has expired"
}
Contact the SportAPI manager to renew access. Do not create a new key yourself or use another client’s key.
Other key states:
error_message | Meaning |
|---|---|
Package is blocked | The key is temporarily paused; its expiration date does not change |
Package is not active yet | The key was issued in advance; its access period has not started yet |
Expiration Date in Every Response
Every successful response contains the X-Key-Expires header with the key’s expiration date
(ISO 8601, UTC):
X-Key-Expires: 2026-11-03T14:34:23.479Z
You can use it to show a renewal reminder in advance without making separate requests.
Several Keys and the account Method
A client can have several keys: a test key and a production key, separate keys for different websites or mirrors. The test key and the production key are always different keys: production access is issued as a new key.
The account method returns data for all
of the client’s keys using any of them: the expiration date, the number of days left,
available sports and languages, access restrictions, the last request time, and the number of
requests for 7 days. The key’s language list is suitable for a language switcher on a website:
it contains only the languages included in the key and available in the line.
Access Restrictions by IP and Website
At the client’s request, a key can be restricted to the IP addresses of the client’s servers and/or to the client’s websites. Then even a copied or leaked key does not work from another server or website.
- IP addresses and subnets — for requests from the client’s server. For example,
203.0.113.7or the subnet198.51.100.0/24(all addresses from198.51.100.0to198.51.100.255). Allow the IP address of the server that sends requests to the API, not the website address. - Websites — for requests directly from a browser:
example.com(this domain only),*.example.com(all subdomains), mirrors as separate entries. The website is determined by theOriginheader, which the browser sets itself.
A request is accepted if its IP address or website is in the list. From another address the API returns:
{
"error_code": 100,
"error_message": "Access from IP 203.0.113.50 is not allowed for this Package"
}
or Access from site example.org is not allowed for this Package for requests from a
browser. The text contains the address to send to the manager so that it can be allowed.
Your current IP address is returned in the your_ip field of the account method.
A website restriction only protects against using the key on another website: a script on a
server can send any Origin header. For reliable protection, send requests from your server
and restrict the key to its IP address.
Authentication Errors
Access errors are returned as JSON with error_code and error_message fields:
{
"error_code": 100,
"error_message": "Invalid Package"
}
When processing a response, check for error_code and error_message instead of
relying only on the HTTP status.
All confirmed errors, their causes, and troubleshooting steps are documented in Error Handling.
Verifying the Connection
Before starting the main integration, verify that:
- You are using the base URL provided by the manager.
- The key is sent in the
Packageheader. - The key is not written to logs or displayed in interface messages.
- The
lineorlivevalue is correctly specified in the URL. - The requested language is included in the subscription.
- The requested sport is available to the key.
- The access period has not expired.
- If the key is restricted to IP addresses or websites, the request is sent from an allowed address.
You can check the state of all your keys with one request:
curl --request GET \
--url 'https://YOUR_API_DOMAIN/v1/account' \
--header 'Package: YOUR_API_KEY'
Make the following request to verify the connection:
curl --request GET \
--url 'https://YOUR_API_DOMAIN/v1/menu/live/en' \
--header 'Package: YOUR_API_KEY'
Support
If access does not work, send the manager:
- the request URL without the key;
- the time when the request was made;
error_codeanderror_message;- the language and sport ID used;
- the environment: local, test, or production.
Do not send the API key in a public chat or public issue.
- SportAPI support: @sportapinet_bot
- Official website: sportapi.net
Next: Core Concepts.