Docs

From sign-up to your first odds in a few minutes. Every call below is a plain HTTPS GET with your key in a header.

1. Get your key. Sign up and confirm your email. Your key is on your dashboard, shown once: copy it then.
2. Set your allowed IP on the dashboard: your server's address. The key works only from there (Authentication).
3. Check the feed and your key. This first call starts your 14-day trial of full Pro: every event, REST and socket.

curl -H "Authorization: Bearer YOUR_KEY" "https://api.tifosports.com/v1/status"

{"data": {"status": "up", "updated_at": "2026-10-04T07:59:23Z", "server_time": "2026-10-04T07:59:23Z", "plan": "pro"}}

4. Load the menu once and cache it: /sports, /countries, /leagues and the market dictionary /markets. Ids never change, so you map them to your own once.

curl -H "Authorization: Bearer YOUR_KEY" "https://api.tifosports.com/v1/sports"
curl -H "Authorization: Bearer YOUR_KEY" "https://api.tifosports.com/v1/markets?sport=8"

5. Load the odds. One call per page gives a sport's events with every market and price. Follow meta.next_cursor until it is null.

curl -H "Authorization: Bearer YOUR_KEY" "https://api.tifosports.com/v1/events?sport=8&state=upcoming&markets=true"

6. Check a bet slip right before you accept a bet: /outcomes?ids= returns each outcome's price, status and result now.
7. Settle. /settlements?event_ids= lists every result of those events, oldest first.
8. Go real-time. Join the WebSocket with any Pusher client: app key 284f4b1f03a30d287df0, host ws.tifosports.com, login at https://api.tifosports.com/v1/ws/auth with the same key. Within 10 seconds the first message arrives:

{"seq": 1204, "at": "2026-10-05T19:14:20.002Z", "status": "up"}

That is feed.alive, the heartbeat. Prices, scores and results follow as they change; the WebSocket guide says what to do with each message, and the Socket recipes end with three sample clients that run with only your key.

9. Show the match. An event with has_tracker: true has a live match tracker: put its tracker_url from REST in an iframe on your page (Match tracker).

GET /v1/account shows when your trial ends (trial_ends_at); pay before then to keep the key working (Plans and billing). To see the data before you write code, open the live board or the settled results on the site.

Your key

Send it on every call as Authorization: Bearer <key>. Never put it in a URL: URLs end up in logs and browser history.

• One key per account. Making a new key on the dashboard revokes the old one at once.
• The key sees every event of every sport on offer. A new account gets 14 days of Pro free, counted from the key's first API call (a REST call or a socket login), not from signup: sign up, read these docs and plan your work without losing a day.
• After the trial, the key works while Pro is paid. Not paid, it stops: every call answers 402 payment_required. Paying switches the same key back on within minutes; nothing to change in your code (Plans and billing).

Your allowed IP

Each key works from one IP address (IPv4 or IPv6): your server's. Set it on your dashboard before the first call; you can change it there any time.

• Every REST call and every socket login from another address answers 403 ip_not_allowed; the message names the address the call came from. A refused call does not start the trial.
• Changing the address closes the key's open sockets within a minute; log in again from the new one.
• Need a second address, for a backup server? Ask support.
• Keep the key on your server. Browsers may call the API (any origin, no cookies), but a key in a web page is a key anyone can copy.

Errors

Every error has the same shape, and the HTTP status says what kind it is:

{"error": {"code": "unauthorized", "message": "Missing, unknown or revoked API key."}}

Read the status before the code: new codes can appear inside v1.

Limits

The same for every key, in the trial and paid:

Ask for compressed responses (Accept-Encoding: gzip, which most HTTP clients send by default): a page of events with markets comes many times smaller.

Ids

Every id is a number. Sports and countries have small ids (8 is football). Every other object has a 9+ digit id whose first digit names its type, so a mixed-up id answers 404, never another object:

Ids are stable: an event keeps its id from upcoming through live to closed, an outcome for the life of its event. Names are labels, never ids: map by id.

Event state

Outcome status

Outcome result

Event stats

The scoreboard beyond the total score: each team's totals (home, away), then each period per team (periods: the period's score and stats), then the game in progress (current, e.g. tennis points and serve). null before kick-off. Period labels: 1H, 2H, ET1, ET2; Q1 to Q4, OT; P1 to P3; sets S1, S2, …; innings I1, I2, …. A sport shows only the stats it has.

Event has_tracker and tracker_url

has_tracker is true when the event has a live match tracker; REST's tracker_url is its address with your tracker key in it, for an iframe on your page (null without a tracker). The socket sends the flag only. See Match tracker.

Rules for every field

• Times are ISO 8601 in UTC (2026-10-03T18:00:00Z).
• Prices are decimal odds (1.91).
• Missing values are null, never left out.
• New values can appear inside v1: treat an unknown result as pending and an unknown status as suspended, and ignore fields you do not know.

An event moves through these states, keeping one id the whole way:

Taken off before kick-off

Matches are sometimes taken off the board days or hours before they start, most often because they are postponed or rescheduled. Such an event becomes suspended: it keeps its id and its markets, every outcome turns suspended, and nothing is bettable. When the match is back, the event returns to upcoming with the same event, market and outcome ids and its outcomes open. If it is published again as a new event (a new date), the old one closes and the new one has its own id. If it is still not back 3 hours after the planned kick-off, it closes. Its bets stay pending; nothing is voided because time passed.

One event from prematch to final whistle

Some sources list the prematch match and the in-play match as two fixtures. The API joins them: you get one event id, and the outcome ids you saw before kick-off stay valid and settle under that id. After kick-off the event shows the in-play markets.

Suspensions

An outcome is suspended while it is offered but not bettable (a goal, a penalty, a dangerous attack), and open again when prices resume. closed means it is no longer offered on this event. Check status before you accept a bet: never take a bet on anything but open.

When the feed is late

/status says up, stale (live data is late: suspend your live markets) or down (suspend everything). The same status arrives on the socket every 10 seconds as feed.alive.

Closing the book on a match

Every event carries settlement: {"settled": …, "pending": …}. Results land after the final whistle, some markets earlier (a first half settles at half time). When pending is 0, the event is fully settled. A match that was not finished keeps its outcomes pending: the feed never voids because time passed, so apply your own void rule and deadline.

A real event in play, light (no markets):

{
  "id": 192227226,
  "sport": {"id": 5, "name": "Baseball"},
  "country": {"id": 62, "name": "Korea (South)"},
  "league": {"id": 294562139, "name": "KBO League"},
  "home": {"id": 516753722, "name": "Hanwha Eagles"},
  "away": {"id": 583174517, "name": "Kiwoom Heroes"},
  "start_time": "2026-10-04T05:00:00Z",
  "state": "live",
  "score": {"home": 3, "away": 9},
  "clock": {"period": "9th Inning", "minute": null, "seconds": null, "running": null, "countdown": false},
  "stats": {"home": {}, "away": {}, "periods": [{"period": "I1", "home": {"score": 0}, "away": {"score": 1}}, {"period": "I2", "home": {"score": 1}, "away": {"score": 0}}], "current": null},
  "settlement": {"settled": 2, "pending": 28},
  "updated_at": "2026-10-04T07:59:09Z"
}

Map the dictionary and the teams to your own once, then every event arrives in terms you already know.

The market dictionary

/markets?sport=8 lists every market a sport can carry, the same for every plan. Each entry is a market (market_id on events) with name templates for its outcomes:

{"id": 353946519, "sport": 8, "name": "Match Result", "group": "result", "order": 1, "has_line": false, "outcomes": ["{home}", "X", "{away}"]}

• {home} and {away} are the teams, {line} the market's line, {player} a player. Markets with open-ended outcomes (players, correct score) list [].
• has_line: true means the market comes in lines (Total Goals 2.5, 3.5, …).

A market on an event

On an event, each market is one line of one dictionary market:

Key your own markets by id, not by market_id + line: some events offer two markets with the same market_id and line at different prices, and they stay two markets.

From a real event, the two main markets:

[
  {"id": 7461549739637, "market_id": 317478958, "name": "Money Line", "line": null, "group": "result", "order": 1, "columns": 2, "main": true,
   "outcomes": [
     {"id": 4274663839, "name": "Kiwoom Heroes", "price": 1.01, "status": "suspended", "result": "pending", "updated_at": "2026-10-04T07:20:04Z"},
     {"id": 4512778987, "name": "Hanwha Eagles", "price": 34, "status": "suspended", "result": "pending", "updated_at": "2026-10-04T07:29:24Z"}
   ]},
  {"id": 7543241778314, "market_id": 372385514, "name": "Totals", "line": 13.5, "group": "totals", "order": 2, "columns": 2, "main": true,
   "outcomes": [
     {"id": 4274663861, "name": "Over 13.5", "price": 1.65, "status": "open", "result": "pending", "updated_at": "2026-10-04T07:59:10Z"},
     {"id": 4197882581, "name": "Under 13.5", "price": 2.2, "status": "open", "result": "pending", "updated_at": "2026-10-04T07:59:10Z"}
   ]}
]

Outcomes come in the source's display order, which is not always home first (the Money Line above lists the away team first). Match outcomes by id, or by the template in the dictionary, never by position.

Teams and leagues

• /teams?sport= gives every team (or player) with a stable id, about 20,000, paged. Map "Man Utd" and "Manchester United" to one team by id once.
• /leagues comes in menu order with its country; /countries in menu order too. Both are full lists: filter on your side.

/v1/events does three jobs: the first load, staying up to date, and recovering after a gap.

The socket is described in Real-time feed and the catch-up in Recover after a disconnect. Without the socket, keep live events current with events?sport=8&state=live&markets=true&since=<last call>: each call carries only what changed.

Light or with markets

• Light (the default): each event's summary, with teams, league, start time, state, score, clock and settled / pending counts. Cheap: use it for fixture lists and menus. Up to 500 a page, 100 by default.
• markets=true: each event with every market and outcome. Up to 50 a page, 10 by default, so a sport's upcoming odds take a few dozen calls, not one per event.

Only what changed: since

since=<ISO time> returns only events where something changed after that time: the score, clock, state, start time, or any outcome's price, status or result. With markets=true, each such event carries only its changed outcomes, inside their markets. Merge them into what you have, keeping the newer updated_at.

• since must be within the last 24 hours. After a longer gap, do a first load again.
• Use the server's clock: take server_time from /status, or the time of your last call minus a few seconds, so nothing falls between two calls.

Other filters

Pages come with meta.next_cursor; pass it back as cursor until it is null. The cursor is opaque: do not build or change it.

Two endpoints, two questions:

Results

Each row of /settlements is one outcome's result, and nothing else:

A withdrawn result comes as a row with pending: undo what you paid on the earlier result. If the outcome is then settled again, a new row with the new result follows. A change from won to lost is simply a row with lost.

{
  "data": [
    {"id": 6719511791, "event_id": 149719948, "outcome_id": 4277663483, "result": "won"},
    {"id": 6182788121, "event_id": 149719948, "outcome_id": 4955221483, "result": "lost"}
  ],
  "meta": {"per_page": 2, "next_cursor": "q7Lw2TfX9bKc4RmNv0sHyA3dJgUe8pZiWo6CtE"}
}

Asking for settlements

• By ids: event_ids (up to 50) or outcome_ids (up to 50); market_ids narrows. For one match or one bet.
• Catch-up: since, a settlement id: you get every result after it, for every sport (add sport to narrow it to one). Start with since=0 for the last 30 days, then keep the last id you processed and resume from it.

Settlement ids are opaque: they are not in size order, so never compare two ids. Rows come in the order they were sent; resume with since.

Applying them safely

• Apply each row once. Store the settlement id you processed; a row you have seen before changes nothing.
• Pay on won / lost / void, undo on pending. Never infer a result from a price or from status.
• pending can last. Nothing settles because time passed: apply your own rules and deadlines.
• The latest row wins. If you only need the state now, ask /outcomes: its result is already the outcome of every row.

One WebSocket connection brings every change as it happens: new events and markets, prices and outcome status, scores, clocks, stats and results. Load once over REST, then let the socket keep you current. Never poll live events.

Connect

The socket speaks the Pusher protocol, so any Pusher client works (JavaScript, PHP, Python, Java, Swift, .NET and more).

import Pusher from 'pusher-js';

const pusher = new Pusher('284f4b1f03a30d287df0', {
  cluster: '',
  wsHost: 'ws.tifosports.com',
  forceTLS: true,
  enabledTransports: ['ws', 'wss'],
  channelAuthorization: {
    endpoint: 'https://api.tifosports.com/v1/ws/auth',
    headers: { Authorization: 'Bearer YOUR_KEY' },
  },
});

const channel = pusher.subscribe('private-feed.pro');
channel.bind_global((name, data) => {
  if (!name.startsWith('pusher:')) handle(name, data);
});

Without a Pusher library (any WebSocket client; the Python sample client does exactly this):

1. Open wss://ws.tifosports.com:443/app/284f4b1f03a30d287df0?protocol=7&client=my-app&version=1.0.
2. The first frame is {"event": "pusher:connection_established", "data": "{\"socket_id\": \"…\", …}"}. data is itself a JSON string, here and in every message: decode it twice.
3. Log in: POST https://api.tifosports.com/v1/ws/auth with your Authorization: Bearer YOUR_KEY header and the form body socket_id=<socket_id>&channel_name=private-feed.pro (application/x-www-form-urlencoded). It answers {"auth": "…", "channel_data": "…"}.
4. Send {"event": "pusher:subscribe", "data": {"channel": "private-feed.pro", "auth": "…", "channel_data": "…"}} with both values as they came. pusher_internal:subscription_succeeded confirms it.
5. Answer every pusher:ping with {"event": "pusher:pong", "data": {}}; pusher:error and pusher:subscription_error mean the join failed. Every frame whose event does not start with pusher is a feed message: event is its name (feed.alive, market.updated and so on) and the decoded data carries seq, at and the object.

2 sockets per key. A third login is never refused: it closes the key's oldest socket, so a reconnect, or a deploy that starts the new process before the old one stops, always gets in. Run at most two clients per key; a third keeps closing the others.

The login answers 403 ip_not_allowed from any address but the key's allowed IP, 402 payment_required once the key has stopped (trial or grace days over, nothing paid) and 403 forbidden for any other channel. Revoking the key, the end of the trial or the grace days, and a change of the allowed IP close the key's sockets within a minute.

One channel carries everything

Your channel carries every public sport, upcoming and live events, markets, stats, results and a heartbeat. If you offer only some sports, skip the rest by sport_id (in event.created: event.sport.id).

The objects are REST's: the same ids, field names and values as GET /v1/events/{id} and GET /v1/settlements. Created is whole, updated is short: a *.created message carries the whole object once; a *.updated message carries only the fields that change.

There are no remove messages. A market the source stops offering stays on its event with every outcome closed and may reopen later under the same ids. At kick-off and when an event closes, only the state goes out; markets follow only where they really changed. Every message and its fields are in the reference below.

Order: seq and at

Every message has seq, which rises by exactly 1 per message on your channel, and at, when we sent it (UTC with milliseconds; against your clock it is your delay).

• seq is the last one plus 1: apply the message.
• seq jumps ahead: you missed messages. Recover, then go on.
• seq at or below one you applied: you have it already; drop it. If it is far below (it started again after a restart on our side), recover.

Heartbeat

feed.alive comes every 10 seconds, also when nothing else happens. No feed.alive for 30 seconds: treat the feed as down, suspend everything, reconnect and recover. GET https://api.tifosports.com/v1/status gives the same status over REST.

The client loop

Every client does the same few things: load once over REST, join the channel, and for each message check seq, apply it, remember seq and at.

let lastSeq = null, lastAt = null;

function handle(name, data) {
  if (lastSeq !== null && data.seq <= lastSeq) return;             // had it already
  if (lastSeq !== null && data.seq !== lastSeq + 1) return recover(); // missed some
  apply(name, data);                                                // the table above
  lastSeq = data.seq;
  lastAt = data.at;
}

Hold the messages that arrive while you recover and apply them afterwards, dropping the ones the catch-up already covered (Recover after a disconnect).

Connections drop. Nothing is lost: REST has everything the socket sent, so a short catch-up puts you back exactly where the socket is.

When to recover

• seq jumped: a message is missing.
• The connection dropped and came back.
• No feed.alive for 30 seconds (reconnect first).
• seq went far below the last one you applied: the counter started again after a restart on our side.
• Your own service restarted. With nothing stored, do a first load instead: the same calls without since.

The four steps

1. Hold new messages. Keep receiving, but put the socket's messages aside while you catch up.
2. Catch up the events. Ask for everything that changed since the last message you applied, with its at:

curl -H "Authorization: Bearer YOUR_KEY" "https://api.tifosports.com/v1/events?markets=true&per_page=50&since=2026-10-03T18:34:15.871Z"

Each event comes with only its changed outcomes, inside their markets. Merge them into what you hold and keep the newer updated_at. Follow meta.next_cursor until it is null. Note the first page's meta.seq: the socket message this answer already covers.

3. Catch up the results. Ask for every result after the last settlement id you applied:

curl -H "Authorization: Bearer YOUR_KEY" "https://api.tifosports.com/v1/settlements?since=651382948"

Apply each row once by id, as you do on the socket. A pending row withdraws an earlier result.

4. Go on with the socket. Apply the messages you held, dropping every one with seq at or below the meta.seq from step 2, and continue as normal.

Good to know

• since reaches 24 hours back for events and 30 days for results. After a longer gap, do a first load.
• Prices are a state, not a change: when REST and the socket disagree, the newer updated_at (or at) wins.
• Suspend your markets while you recover if it takes more than a few seconds: you are not sure of the prices until step 4.
• After a restart on our side every event may come once more as event.created: replace what you hold, as always.
• Recovery after a long downtime and the first load are the same calls; only since differs.

Seven jobs every sportsbook does with the socket, each in a few lines. The sample clients at the end of this page do all of them; the code below is JavaScript, the same steps work in any language.

Keep a live coupon in sync

Load once over REST, then let the socket keep every event current. The objects are REST's, so one set of code reads both.

1. First load: GET https://api.tifosports.com/v1/events?markets=true&per_page=50 for the states you show (state takes one value: one load per state), every page. Note the first page's meta.seq of the first load: it is the lowest, and the later loads are newer still.
2. Join your channel and drop every message with seq at or below that meta.seq.
3. Apply each message:

switch (name) {
  case 'event.created':  events.set(data.event.id, data.event); break;          // replace, never merge
  case 'market.created': upsertMarket(events.get(data.event_id), data.market); break;
  case 'market.updated': for (const o of data.outcomes) setOutcome(data.event_market_id, o.id, o.price, o.status); break;
  case 'event.updated':  Object.assign(events.get(data.event_id), pick(data, 'start_time', 'state', 'score', 'clock')); break;
}

A *.created message is the whole object: replace what you hold. A market.updated lists only the outcomes that changed: set their price and status and leave the others. A market never disappears; when it stops, its outcomes go closed, and it may come back later with the same ids.

Stop bets at the right moment

Take a bet on an outcome only when all of these hold:

• the outcome's status is open (not suspended, closed or settled);
• its event's state is upcoming or live, never suspended or closed;
• the last feed.alive said up and came less than 30 seconds ago.

feed.alive stale means live prices may be behind: suspend your live markets and keep upcoming ones. down, or no feed.alive for 30 seconds: suspend everything, reconnect and recover. When the check passes, re-read the price at the moment of acceptance: the price you hold now is the price, not the one on the bet slip.

Show the match

event.updated carries score and clock on every change: a goal, a period, the clock starting or stopping. stats.updated carries the whole stats object (corners, cards, aces, fouls … by sport; names in the glossary): replace yours.

For the match itself on your page, use the tracker: has_tracker on event.created, the address from REST (Match tracker).

Run the clock yourself between updates instead of waiting for one every second:

function clockNow(clock, receivedAt) {
  if (!clock || !clock.running) return clock?.seconds ?? null;
  const passed = Math.floor((Date.now() - receivedAt) / 1000);
  return clock.countdown ? Math.max(0, clock.seconds - passed) : clock.seconds + passed;
}

clock is null before kick-off and after the end. Sports without a running clock (tennis and the other set sports, darts) send only its period, such as 2nd Set, with minute, seconds and running null: read stats for sets and games. In basketball and ice hockey running is null and countdown is true: the time left comes in 15-second steps, so show the last one.

Settle bets from the socket

A settlements message carries up to 100 rows, each {id, event_id, outcome_id, result}:

for (const row of data.settlements) {
  if (applied.has(row.id)) continue;          // apply each id once
  applied.add(row.id);
  if (row.result === 'pending') ungrade(row.outcome_id);  // a result withdrawn
  else grade(row.outcome_id, row.result);                 // won, lost or void
  lastSettlementId = row.id;                              // where a catch-up starts
}

• Match bets by outcome_id: it is the id the bet was placed on, before or during the match.
• A pending row withdraws an earlier result of that outcome; a new row follows when it is settled again. Grade by the newest row.
• Markets settle as soon as the match decides them, so many settle during play. An accumulator settles when its last leg does.
• After a gap, GET https://api.tifosports.com/v1/settlements?since={last id} returns every row you missed (Recover after a disconnect).

Recover after a disconnect

Watch seq: it rises by exactly 1 per message. A jump, a dropped connection or 30 seconds without feed.alive means you may have missed something. Hold new messages, ask REST what changed since your last at and every result since your last settlement id, then go on from the catch-up's meta.seq. The four steps are in Recover after a disconnect; the sample clients do it in about 40 lines.

Take only the sports you offer

There is one channel, private-feed.pro, with every public sport. Skip what you do not offer:

const offered = new Set([1, 4]);   // sport ids from GET https://api.tifosports.com/v1/sports
function wanted(name, data) {
  if (name === 'event.created') return offered.has(data.event.sport.id);
  if (name === 'feed.alive' || name === 'settlements') return true;
  return events.has(data.event_id);  // only events you kept
}

Keep the seq check on every message, skipped ones included: a gap is a gap whatever the sport. For settlements, keep the rows whose event_id you hold.

What happens at kick-off and when an event closes

• Kick-off. event.updated with state: live comes at once, under the same event id as before. Then, as the live markets arrive, market.created for markets new to the event and market.updated for ones that changed; nothing for the rest. Markets that do not carry on in play go closed through market.updated. Bets you took before kick-off keep their outcome ids and settle by them.
• Stats start with the first stats.updated after kick-off.
• An event taken off before kick-off (most often postponed or rescheduled): event.updated with state: suspended, then its outcomes go suspended through market.updated. Nothing is bettable. When it is back, event.updated with state: upcoming and its outcomes open again, under the same ids. Not back 3 hours after the planned kick-off: it closes.
• The end. Only event.updated with state: closed. Treat every market of a closed event as closed, whatever its outcomes say; results keep coming in settlements.
• An event that comes back after closing (a match resumed): event.updated with upcoming or live, then only the markets that changed while it was closed.

Sample clients

Three small clients that do everything on this page: load over REST, join the channel, apply every message to the events they hold, print each one, and recover on a seq gap or a reconnect. Set LOF_KEY (your API key) and LOF_APP_KEY (284f4b1f03a30d287df0) and run.

A live match tracker for your event pages: the match drawn on a pitch or court as it is played. Put it on your site with one iframe.

Where the address comes from

The address holds your own tracker key (?k=), so only REST sends it: the socket sends the same message to every customer. When an event.created arrives with has_tracker: true, read the event once:

curl "https://api.tifosports.com/v1/v1/events/142244893" \
  -H "Authorization: Bearer YOUR_API_KEY"

{
  "data": {
    "id": 142244893,
    "has_tracker": true,
    "tracker_url": "https://addons.tifosports.com/m/51234567?k=h7Gq2LmZ0pW4sXc9VbN1"
  }
}

The tracker often comes at kick-off, after the event was first sent. Then event.created comes again, whole, with has_tracker: true; event.updated never carries it. Without the socket, has_tracker and tracker_url are on every /v1/events page too.

Put it on your page

Use tracker_url as it is; do not change the address or drop ?k=. Any website may frame it: no domain to register.

<iframe src="https://addons.tifosports.com/m/51234567?k=h7Gq2LmZ0pW4sXc9VbN1"
        width="340" height="322" style="border:0;overflow:hidden"
        loading="lazy" title="Match tracker"></iframe>

The tracker follows the match by itself: no calls from your side while it runs. After the final whistle it shows the final; has_tracker stays true.

Your tracker key

• It is on your dashboard, beside your API key, and already inside every tracker_url we send you.
• It is public: it sits in your page source and opens only the tracker. Your API key never goes in a page.
• A new API key gets a new tracker key. Read tracker_url again from REST after you make one.
• It works while your API key works: in the trial or while Pro is paid. A frame that says Tracker not available has no key, an old key, or a key whose plan has stopped.
• Views are counted per key, per day and per website that shows the tracker (the site's address only, never your visitors'), so a key copied to another site shows up.

What the feed gives a sportsbook, and what stays your own rule.

Not in the feed: bet placement, bet slips, ticket acceptance, liability, cash-out and bet-builder pricing. Those are your platform.

1. Menu, lists and event pages

Load /sports, /countries and /leagues once a day and show them in the order they come. For fixture lists without odds, call /events light; for lists with odds, /events?markets=true and show the markets with main: true. On an event page, show the markets sorted by order, tabbed by group, columns outcomes per row.

2. Accepting a bet

Right before you accept, ask /outcomes?ids= with every leg of the slip:

• the price is the one the customer saw (or within your tolerance);
• status is open (an outcome of a closed event is closed).

In play, wait your delay (often a few seconds), then ask again. Anything changed: reject or re-offer.

3. Settling

Catch up on /settlements?since= (or by event_ids) and apply each row once, by id. Pay singles on won / lost / void. Grade an accumulator when every leg has a result; a void leg usually counts as odds 1.00. On a row with result: pending, undo the payment of the result it withdraws; a new result follows later.

4. The hard cases

• Postponed before kick-off: the event goes suspended with every outcome suspended; it comes back as upcoming with the same ids, or closes if it is not back 3 hours after the planned kick-off.
• Abandoned: the event goes closed and its outcomes stay pending; your rules decide when a bet is void.
• Feed trouble: when /status is stale, suspend live markets; when down, suspend everything.

Best practices

• Cache the catalogue. Sports, countries, leagues, teams and the market dictionary change rarely: load them once a day.
• Never poll per event. Use pages with markets=true and since, then the socket.
• Keep the newer one. When REST and socket data meet, keep the row with the newer updated_at.
• Apply settlements once, by id, and resume catch-up from the last id you processed.
• Watch /status. Suspend live markets on stale and everything on down.
• Keep the key on your server, and send Accept-Encoding: gzip.

Report a security issue

Found a weakness in the API, the socket or the site? Write to support@tifosports.com (also in security.txt) with the steps to see it. Please do not test against other customers' keys or data.

One plan, Pro: every event in every sport, live and prematch, on one key. $750 a month, or $7,500 a year (2 months free, $625 a month). Paid in crypto (Bitcoin), by the calendar month or the year. No contract, no automatic charge. Prices: pricing.

The 14-day trial

• 14 days of full Pro, free, once per account and once per company. No payment to start.
• The days start at your key's first API call (a REST call or a socket login from its allowed IP), not at signup. Sign up, read the docs, set your allowed IP and plan the work first.
• Any 14 days hold two Saturdays and two Sundays: test the socket on a busy weekend evening.
• GET /v1/account shows state: trial and trial_ends_at. We email you when the trial starts, 3 days before it ends and on its last day.
• Pay any time during the trial: the paid month or year starts when the trial ends, so you lose no trial day. Not paid when it ends, the key stops: every call answers 402 payment_required and socket logins are refused, until you pay.

Pay, step by step

1. Open your billing page and pick Monthly (preselected) or Yearly (2 months free). The total is in US dollars.
2. Continue to payment opens our checkout (BTCPay Server, open source, on our own domain). It shows the exact amount, the network and the address. The amount is held for 30 minutes.
3. Send the payment from your wallet or an exchange. From an exchange, set the amount the address must receive: the network fee comes on top. Send Bitcoin on the Bitcoin network only (not Lightning).
4. Come back to the invoice page (the checkout sends you there). It follows the payment live:

Confirming

Pro starts as soon as your payment is seen on the network. It is final when the network confirms it: usually 10 to 30 minutes for Bitcoin (longer when the network is busy). If a payment never confirms, Pro pauses, we email you, and your next payments give Pro only once they confirm.

When your key works

The key stays the same through every step: paying a stopped key switches it back on within minutes, nothing to redeploy. Log in to the socket again after paying.

Watch the end from your system

GET /v1/account says when the key would stop: state (trial, pro, grace or stopped), trial_ends_at, interval, ends_at, grace_until, confirming and renew_url. Alert yourself a week ahead:

curl -s -H "Authorization: Bearer YOUR_KEY" "https://api.tifosports.com/v1/account" \
  | jq -r '.data | (.ends_at // .trial_ends_at) as $end | select($end != null) | select(($end | fromdateiso8601) - now < 7*86400) | "The key stops after \($end): pay at \(.renew_url)"'

Renewal, monthly or yearly, grace

• Reminders by email 7, 3 and 1 day before the end, with a Renew button. Switch them off on your billing page if you will not renew.
• Renew early any time: the next month or year starts when the current one ends, so you never lose a day.
• Switch between monthly and yearly when you pay the next period. There is no change in the middle of a period.
• A month runs from a day to the same day of the next month (12 October to 12 November; from 31 January the next ends 28 February). A year is twelve such months.
• Grace: not renewed, your key keeps working for 7 more days. Paying in those days starts the new period at the old end. Then the key stops until you pay.

Receipts and payment details

Every confirmed payment has a receipt (PDF) with your company details: add your company, address, country, tax number and billing emails on the billing page (new receipts use them). Before paying, your finance team can download a pro-forma; it is not a receipt. Your history lists every invoice with its transaction, and downloads as CSV.

When something goes wrong

• Short: send the rest before the time ends. A payment up to 3% short counts in full.
• Late: a full payment within 2 hours of the invoice time counts at the held price; later, support contacts you.
• Twice: both count (two periods, or an extra support settles with you).
• Wrong network or coin: write to support with the invoice number and the transaction. We help, but cannot promise to recover funds sent where the checkout did not show.

Payments are final; to stop, simply do not pay the next month. Questions: reply to any billing email, or use the support links on the dashboard.

Most customers pay from an exchange account (Binance, OKX, Bybit or another). That works well. Three things decide whether the payment lands: the network, the amount that arrives, and the time. This page walks through them, then the exact taps on the biggest exchanges. Start from your billing page: Go Pro, pick monthly or yearly, Continue to payment.

The three rules

1. The network. Bitcoin only on the Bitcoin network (not BEP20, not Lightning). The payment page shows the network under the amount. A payment on another network does not arrive here and may be lost.
2. The amount that arrives. The address must receive the full amount the payment page shows. Exchanges take their fee from what you type unless you tell them otherwise: on Binance choose Receive amount and type the amount from the payment page; elsewhere type that amount plus the fee the exchange shows. Up to 3% short still counts in full.
3. The time. The payment page holds the price for 30 minutes. Exchanges sometimes hold a withdrawal for a security check, above all the first one to a new address. A payment you sent in time that arrives up to 2 hours after the page's time still counts by itself; later, support sorts it out with you.

Use the address shown on this payment page, every time: it can change from one payment to the next. Do not save it in your exchange's whitelist for later payments.

Copy or scan the address

• Copy: the copy button next to the address on the payment page, then paste it into the exchange's address field. Check the first and last four characters after pasting.
• Scan: open the payment page on your computer; in your exchange app's withdraw screen, tap the scan icon in the address field and point the phone at the QR code. Check the address it filled in, then choose the network and the amount yourself.

Binance

App (Binance's own steps, September 2026):

1. Assets → Overview → Send → Withdraw Asset.
2. Choose BTC and the account to send from.
3. Paste or scan the address. Choose the network: Bitcoin.
4. Amount: choose Receive amount and type exactly the amount from the payment page. The app shows the fee on top.
5. Withdraw, check the address and the network, slide to confirm, then your passkey or 2FA. The first withdrawal to an address shows a safety notice: that is normal.

Website: Assets → Overview → Withdraw → Withdraw Asset → the coin → Address: paste it, check the network → the amount → Withdraw → Confirm → Continue → the security checks.

OKX

1. Assets → Withdraw → Withdraw crypto (on-chain), then BTC.
2. Paste or scan the address and choose the network: Bitcoin.
3. Type the amount so that what arrives is the amount on the payment page (OKX shows its fee and the minimum).
4. 2FA, then confirm. The status goes Pending → Withdrawing → Completed.

OKX asks for identity verification before the first withdrawal.

Bybit

1. Assets → Funding account → Withdraw. Coins in the Unified Trading Account move to Funding first.
2. Search BTC, paste or scan the address, choose the network Bitcoin and the amount so that the payment page's amount arrives.
3. Withdraw, then the email or phone code and Google Authenticator. Bybit may take up to an hour to send.

Any other exchange

The same three rules: withdraw (sometimes "send" or "transfer out") on-chain, the address from the payment page, the network Bitcoin, and an amount that makes the payment page's amount arrive after the exchange's fee.

Afraid of sending it all at once? Send a little first

You can split one payment: send a small amount first, see it arrive, then send the rest to the same payment page.

1. Send a small amount, above your exchange's minimum.
2. Wait until the payment page says Part of your payment arrived; it shows how much is left.
3. Send exactly what is left, on the same network. Pro starts when the whole amount is there.

Send the rest before the page's time ends; if your exchange holds it, it still counts when it arrives within 2 hours of that time. Each withdrawal costs the exchange's fee again. Do not send a test to an old payment page: open a new one from your billing page.

After you send

The invoice page (the payment page sends you back to it) follows the payment live: Payment received. Pro is on. as soon as it is on the network, then Paid when it confirms, usually 10 to 30 minutes for Bitcoin. The receipt comes by email. Keep the transaction id (TXID) from your exchange's history: support asks for it if anything looks wrong.

Sent on the wrong network or the wrong coin? Write to support with the invoice number and the TXID. We help where we can, but cannot promise to recover funds sent where the payment page did not show.