Football API questions.
No hidden capabilities.

Stats API is a versioned JSON REST API for football data. Its current open-data beta covers competitions, seasons, teams, fixtures, and results through stable Stats API identifiers. Customer accounts, API keys, authenticated requests, usage limits, and the three paid plan checkouts are available; planned data categories remain clearly marked until their sources are licensed and validated.

The current bootstrap dataset contains competition, season, team, fixture, and result records sourced from the CC0 OpenFootball project. Exact live counts and competition coverage are shown on the coverage page. Player statistics, lineups, injuries, odds, expected goals, predictions, and live event feeds are not currently available.

Not today. Live scores and football odds remain roadmap capabilities until Stats API has a feed with explicit commercial redistribution rights, measured freshness, and production validation. The public contract never marks a planned capability as available.

The current bootstrap data comes from the OpenFootball project and is offered under CC0 or public-domain terms. Stats API normalizes it into stable public resources and records source and license information in a public data-source ledger. Future providers must pass rights, freshness, and quality review before their data is exposed.

Stats API publishes an OpenAPI 3.1 contract, llms.txt orientation, stable resource IDs, UTC timestamps, explicit availability, and predictable error envelopes. A server-side agent tool can use these artifacts to retrieve facts without guessing routes or fields, while keeping the private API key outside the model context.

An agent can eventually use available fixtures and historical results as grounded inputs to a model you operate, but Stats API does not currently provide a prediction endpoint. Any probability or score estimate must be labeled as a model output, with its inputs, assumptions, evaluation, and uncertainty kept separate from API facts.

Use API tool calls for current structured facts such as fixtures, results, statuses, and stable IDs. Use retrieval for durable explanatory material such as documentation and policies. Mixed questions can use both, provided the final answer preserves provenance and does not let retrieved prose override current structured data.

Authenticated API requests use a bearer API key in the Authorization header. Create and revoke keys in the customer dashboard. Keys must remain in server-side environment configuration and must never be placed in query strings, public browser code, logs, or source control.

Yes. Public competition, season, team, and match IDs belong to the Stats API contract rather than to an upstream provider. Provider identifiers remain internal crosswalk data, allowing the ingestion source to change without forcing customers to rewrite stored public IDs.

Customer requests are designed to read versioned Redis responses or normalized MySQL data and never wait on an upstream provider. Cache and source freshness are separate concepts. Exact refresh targets depend on the resource and source; every production capability must expose enough timing information for an application to qualify time-sensitive answers.

Yes. Every request admitted through the per-minute limit counts once toward the billing-period quota, including a Redis cache hit and an application-level error produced after authentication. Authentication failures and requests rejected by the per-minute limiter do not consume the billing-period quota. Limits are shared across an account’s API keys.

Integrations should explicitly handle 401 for invalid credentials, 404 for an unknown resource, 422 for invalid parameters, 429 for a rate or quota limit, and 503 for temporary unavailability. Retry only temporary failures, honor Retry-After, and never invent a fallback identifier or field.

The monthly tiers are Starter at 39 USD, Growth at 99 USD, and Scale at 299 USD. They enforce different monthly and per-minute request limits while including every currently available endpoint. The exact price, trial, and renewal terms are shown again in Polar before checkout is confirmed.

The configured Starter, Growth, and Scale products each include one seven-day trial managed by Polar. Creating a Stats API account does not start a second trial or grant API access. The trial begins only through the selected Polar checkout, whose confirmation screen is authoritative for the product, renewal date, and amount.

Billing is provided through Polar. Polar emails each customer a secure link to its hosted portal, where the customer can review invoices, update payment details, and cancel the subscription. Access after cancellation follows the paid period and product terms shown at checkout.

The public refund policy explains cancellation and refund eligibility, including mandatory consumer rights that may apply. Billing decisions depend on the transaction and applicable law. Contact support with the account email and transaction reference, but never send an API key or password.

Stats API uses privacy-conscious first-party and Firebase analytics to understand public and signed-in product journeys. First-party records keep the page path, coarse device class, and limited attribution; signed-in page views are linked to the internal account. Firebase receives sanitized paths, bounded interaction categories, and a one-way pseudonymous account identifier for signed-in users. Analytics excludes names, emails, URL query strings, form contents, API keys, request payloads, raw IP addresses, and full user-agent strings from application analytics records. Global Privacy Control and Do Not Track are honored, known bots are excluded, and browser-derived visitor hashes rotate daily.

Use the support address on the contact page and include the affected public resource ID, request ID, UTC time, and a concise reproduction. Do not send private API keys, passwords, Polar tokens, or other secrets. Data-quality reports are reviewed against retained source and ingestion evidence.