Pulling football data out of 1xBet is less about scraping and more about knowing which door to knock on. The operator does not run a public, self-serve developer portal the way some data vendors do; access runs through 1xBet Partners, and the free tier is deliberately tight. Here is the exact path I use: request a key, wire it into a small client, and normalise the payload before it touches your database.
Getting an API key through 1xBet Partners
The first thing to understand is that 1xBet was founded in 2017 and is operated by 1xCorp N.V., with the group citing licence Curaçao eGaming OGL/2024/1262/0493. That corporate structure matters for integration because the statistics feed is bundled with the affiliate and partner stack rather than sold as a standalone product. You register under 1xBet Partners, complete the account verification, and then request API access from the partner dashboard. Approval is manual in most cases, so budget two to five working days before you have a key in hand.
Once approved, the free tier gives you 100 requests per day and deliberately excludes live in-play data. That last point trips up most people. If your product needs minute-by-minute odds movement or in-game score updates, the free key will not carry you, and you should plan for a commercial agreement from day one. For pre-match fixtures, historical results, team stats and settled markets, 100 calls a day is workable if you cache aggressively and never poll the same endpoint twice in a session.
Store the key in an environment variable, not in source control. Treat it like a payment credential, because that is effectively what it is: a leak means someone else burns your daily quota, and rate limits are enforced per key, not per IP. The 1xBet support service can rotate a compromised key, but the downtime while you wait is entirely avoidable.
Request headers and the first authenticated call
Authenticated calls expect the key in a request header, typically something like Authorization: Bearer YOUR_KEY or an X-API-Key field depending on the endpoint family you were granted. Send Accept: application/json and set a short timeout, 5 seconds is plenty for statistics endpoints. Your very first call should be a lightweight one, a competitions list or a single fixture lookup, purely to confirm the key resolves and to see the real response envelope before you write any parsing code.
Log the raw response to a file on that first run. The field naming in 1xBet’s payloads is not always self-explanatory, and a fixture object may nest team names, kickoff timestamps and market identifiers in ways that only become obvious when you read the actual JSON. Guessing the schema wastes more time than inspecting it once.
Normalising fixtures, markets and odds before storage
Raw API data is a transport format, not a database schema. Before anything hits Postgres or your cache layer, flatten it. Map each fixture to a stable internal ID, store kickoff time in UTC as an integer, and keep the provider’s own fixture ID as a secondary column so you can reconcile later. Team names arrive inconsistently across competitions, so maintain a mapping table that resolves « Man City », « Manchester City » and « Man. City » to one canonical entity. Skip this and your historical queries will silently fragment.
Odds deserve separate treatment. A bookmaker publishes 1X2, over/under, both-teams-to-score and dozens of derivative markets, and each one has its own identifier that changes between seasons. Store the market type, the selection, the decimal price and a timestamp for every quote. 1xbet website offers additional context worth reviewing. That timestamp is the whole point: without it you cannot reconstruct line movement, and line movement is where the analytical value sits. If you are building anything that touches value detection, the historical odds series is the asset, not the current price.
Sports betting and casino share the same account infrastructure at 1xBet, but the statistics API is a football-first product. Do not assume the same endpoint shape covers esports betting or tennis; the coverage varies and some verticals are simply not exposed through the partner feed. Test each sport you intend to support before you promise it to users.
Wiring the feed into a production betting product
The free tier’s 100 requests per day forces a specific architecture. Pull once, store, and serve everything from your own store. A nightly job at 03:00 UTC that fetches the next 72 hours of fixtures and their pre-match markets will consume maybe 40 to 60 calls. The rest of the quota is headroom for manual refreshes and retries. Never let a user-facing request trigger a live API call, because a single traffic spike will exhaust the quota and take the whole feed down for the remaining hours of the day.
Handle failures explicitly. Distinguish between a 401 (bad or expired key, stop and alert), a 429 (quota exhausted, back off until the daily reset) and a 5xx (transient, retry with exponential backoff capped at three attempts). Write idempotent upserts keyed on provider fixture ID plus timestamp so a retry never duplicates rows. If you are feeding a 1xBet app or a companion tool, cache the normalised output at the edge with a 60-second TTL for pre-match data; there is no reason to hit your own database for every page view.
Compliance is not optional here. If your product surfaces 1xBet bonuses, a welcome package or a 30% Cashback Bonus alongside the data, you are operating in a regulated space and need to respect the affiliate terms you signed, including jurisdiction restrictions and advertising standards. The gambling licence held by the operator does not transfer to you. Your integration is your own liability, and the partner agreement will say so in plain language.
One clarification worth stating because it comes up constantly in search results: 1xbets.bet is not the official 1xBet website. If you are looking for API documentation and land on a mirror or an unaffiliated domain, you are in the wrong place. Go through the partner portal you were approved on, and use the support channel attached to that account for any schema questions. Third-party mirrors cannot issue keys and cannot help you when a field changes.
Start small. Get the key, make one authenticated call, dump the JSON, and write the normaliser before you write anything else. Once fixtures and odds land cleanly in your own tables, the rest of the product, whether that is a stats dashboard, an odds comparison view or a research tool, is just presentation. The hard part is the pipeline, and the pipeline is decided by the quota you were given, not by how clever your code is.