Football API questions.
No hidden capabilities.

Stats API is a versioned JSON REST API for football data. Its current public contract covers competitions, seasons, teams, fixtures, and results through stable Stats API identifiers. The site is in a public documentation preview while production data and customer access are being 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. Keys must remain in server-side environment configuration and must never be placed in query strings, public browser code, logs, or source control. API key creation remains paused during the documentation preview.

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 authenticated request counts toward the account quota, including a cache hit and an error returned after successful authentication. This keeps usage accounting predictable and prevents multiple API keys from multiplying one account’s monthly or per-minute allowance.

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 planned 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. Pricing is visible for evaluation, but checkout and customer access remain paused until the production launch gates are deliberately opened.

The configured Starter, Growth, and Scale products each include a seven-day trial. Trials will become available only when account creation, API access, and billing are opened together after production validation. No trial is active merely because the pricing page is public.

Billing is provided through Polar. When subscriptions open, Polar’s hosted customer portal will let customers review and cancel billing, and Polar emails customers a portal link. 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 analytics for approximate traffic reporting. It does not store a raw IP address or full user-agent string in the analytics table, honors Global Privacy Control and Do Not Track, excludes known bots, and rotates the pseudonymous visitor hash 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.