Skip to content
Sports API

Integration

What are API rate limits and credits?

Rate limits and usage credits protect provider infrastructure and define the capacity of a subscription. They are related but not identical. Understanding how your feed counts activity helps prevent empty scoreboards, unexpected restrictions and an integration that appears inexpensive until its scheduled jobs begin running.

Updated

Published · Updated · Sources checked

Request frequency and credit allowance are shown as separate controls on API usage
A rate limit controls request activity; a credit system can assign different costs to different requests.

Short answer

A rate limit restricts requests over a defined period or resource bucket. Credits measure billable usage and may charge different amounts for different endpoints or parameters. Check the provider's rules, remaining-usage metadata and reset window. An HTTP 429 response generally means a rate restriction has been reached.

Identify the unit your supplier counts

One HTTP request is not necessarily one credit. The Odds API documents costs that depend on requested markets and regions for its odds endpoint, with other endpoints following different rules. Sportmonks describes entity-based limits that can be shared by several endpoints. Write down the rule for each operation your application actually performs rather than assuming every address has a separate allowance.

Sources: [2] The Odds API: API v4 documentation and quota costs, [3] Sportmonks: API FAQ, coverage, billing and troubleshooting

Calculate the workload before launch

One polling loop running every five seconds makes 720 requests per hour. Multiply by independent jobs and include test environments, administration tools and retries. Then apply the provider's credit formula where relevant. This arithmetic is an illustrative workload, not a recommended schedule. Our update-frequency guide explains why repeated requests may not produce new data.

Sources: [3] Sportmonks: API FAQ, coverage, billing and troubleshooting

Monitor the metadata supplied with responses

The Odds API documents remaining, used and last-request usage headers. Sportmonks supplies rate-limit metadata including the relevant entity and reset information. Use the fields documented for your product and alert before the allowance is exhausted. Do not calculate every reset as midnight or the billing date unless the provider explicitly defines it that way.

Sources: [2] The Odds API: API v4 documentation and quota costs, [3] Sportmonks: API FAQ, coverage, billing and troubleshooting

Respond correctly to a restriction

MDN explains that HTTP 429 means too many requests and may include a Retry-After header. Respect documented reset information and use bounded retries rather than an immediate loop. Some services express account or quota problems through other responses, so inspect the body as well as the code. The outage guide distinguishes these failures from genuine service unavailability.

Sources: [1] MDN: HTTP 429 Too Many Requests

Reduce unnecessary requests safely

Cache permitted reference data, combine supported queries and avoid requesting fields you do not need. Share appropriate responses across visitors instead of duplicating identical upstream calls. Keep private credentials on the server so outsiders cannot consume the account's allowance. Our key security guide explains why quotas and credential protection belong in the same operational plan.

Sources: [3] Sportmonks: API FAQ, coverage, billing and troubleshooting

Plan for growth without evading restrictions

Leave capacity for busy event periods and diagnose unexpected usage before upgrading blindly. Count all applications sharing the subscription. If the workload exceeds the allowance, negotiate the correct package or redesign the feature. Creating extra accounts to bypass restrictions is not a substitute for a permitted usage plan. Review the cost guide when modelling a larger service.

Keep a request inventory listing each scheduled job, its interval and the account it uses. Include staging environments, exports and monitoring checks, not just the main website. During an incident, this inventory helps identify an accidental duplicate loop or newly added endpoint. Review it whenever another feature launches. A clear usage map is usually more useful than an unexplained counter, because it connects the remaining allowance to the operations your team can actually reduce or reschedule. Check shared account activity before rescheduling.

Sources: [3] Sportmonks: API FAQ, coverage, billing and troubleshooting

Frequently asked questions

Are rate limits always monthly?

No. Windows may be measured in seconds, minutes, hours or another period. Credit resets and billing cycles can also differ.

Does a failed request use credits?

It depends on the endpoint and provider. Check documented charging behaviour and returned usage metadata instead of assuming failures are free.

Should I retry a 429 response immediately?

No. Follow the documented reset or Retry-After guidance where supplied, and use a bounded policy that avoids repeated bursts.

Can several websites share one allowance?

Technically they may share the same account usage, but the licence must also permit those websites. Check both the contract and capacity.

Sources

Checked . Documentation and terms change, so confirm details with the provider before you build.

  1. MDN: HTTP 429 Too Many Requestshttps://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/429
  2. The Odds API: API v4 documentation and quota costshttps://the-odds-api.com/liveapi/guides/v4/
  3. Sportmonks: API FAQ, coverage, billing and troubleshootinghttps://docs.sportmonks.com/v3/api-faq

Related guides