Football data API documentation

A REST API over HTTPS. Responses are JSON, timestamps are UTC ISO-8601, and every list endpoint pages the same way. Authenticate by passing your key as a bearer token. 13 endpoints, covering clubs, players and competitions.

Base URL

https://api.tactics11.com/v1/data

Authentication

curl "https://api.tactics11.com/v1/data/players?position=CF&minRating=80" \
  -H "Authorization: Bearer t11_live_xxxxxxxxxxxx"

The key is the only credential these routes accept - a signed-in browser session gets no pass. The reverse holds too: a key works here and nowhere else in the product, and everything here is a GET, so a leaked key can read your world’s football and can never act as its owner in the game.

What the data is

Your own world. A key belongs to an Annual Member, who chooses one world they manage on their API Hub page, and every endpoint answers for that world - its clubs, its squads, its competitions, its tables and its fixtures, moving as the world moves. Call GET /world first to see which one you are pointed at. A lapsed membership answers 403 MEMBERSHIP_REQUIRED until it is renewed.

It used to be a synthetic universe of its own, seeded once and unrelated to the game. That kept the shape stable and made the API useless: the first thing anybody wants a key for is their own club, and what they got was a league nobody plays in.

Public, and read-only. Everything reachable through a key is what the world browser already shows a signed-out visitor. No budget, no bid, no inbox, no account, no manager’s private anything - and nothing behind these routes can write a row, so a leaked key can read football and can never act as its owner. There is no live-scores endpoint: a match in progress is not a public fact until it is over.

Paging

List endpoints return 20 rows a page. Pass page (from 0) and read X-Has-More: while it is true, ask for the next page. Every sort is stable, so pages never overlap.

Rate limits & errors

Two limits, both per account and shared by every key you hold, so a second key is a second environment rather than a second quota: 10 requests a minute and 100 requests a day, the daily count resetting at 00:00 UTC (see your allowance). Every response carries X-RateLimit-Limit, X-RateLimit-Remaining and X-RateLimit-Reset for the daily quota, so you can back off before you are refused. Exceeding the minute limit returns 429 RATE_LIMITED, the daily one 429 QUOTA_EXCEEDED, both with Retry-After. Refused requests do not count against your quota.

A missing, unknown or revoked key returns 401 INVALID_KEY. More than 5 of those a minute from one address returns 429 RATE_LIMITED until the minute is up, so fix the key rather than retrying it.

Every response - success or failure - uses one envelope: {"success": true, "data": …} or {"success": false, "message": "…"}.

Pick an endpoint from the menu to see parameters and a sample response.