football-docs 0.5.1 → 0.5.2
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README.md +4 -2
- package/data/docs.db +0 -0
- package/docs/fmdb-pro/api-access.md +120 -0
- package/docs/fmdb-pro/api-endpoints.md +123 -0
- package/docs/fmdb-pro/data-model.md +124 -0
- package/docs/fmdb-pro/identity-surfaces.md +123 -0
- package/docs/transferroom/api-access.md +91 -0
- package/docs/transferroom/api-endpoints.md +257 -0
- package/docs/transferroom/data-model.md +143 -0
- package/docs/transferroom/identity-surfaces.md +132 -0
- package/package.json +1 -1
- package/providers.json +22 -0
package/README.md
CHANGED
|
@@ -4,7 +4,7 @@ Searchable football data provider and tooling documentation for AI coding agents
|
|
|
4
4
|
|
|
5
5
|
**Who it's for:** Developers and analysts who use AI coding tools (Claude Code, Cursor, VS Code Copilot) to work with football data. Works with any tool that supports MCP.
|
|
6
6
|
|
|
7
|
-
**What it does:** Gives your AI agent a searchable index of documentation for
|
|
7
|
+
**What it does:** Gives your AI agent a searchable index of documentation for 17 football data providers and tools — event types, qualifier IDs, coordinate systems, API endpoints, data models, identity surfaces, and cross-provider comparisons for the data providers (StatsBomb, Opta, Wyscout, Impect, SkillCorner, FMDB Pro, TransferRoom, and more), plus the open-source libraries people build with (kloppy, mplsoccer, socceraction, soccerdata, and more). Your agent looks up the real docs instead of guessing from training data.
|
|
8
8
|
|
|
9
9
|
**Why not just let the AI figure it out?** LLMs get football data specifics wrong constantly — Opta qualifier IDs, StatsBomb coordinate ranges, API endpoint URLs, library method signatures. These are mutable facts that change across versions. football-docs gives the agent verified, sourced documentation with provenance tracking so you know where every answer came from.
|
|
10
10
|
|
|
@@ -106,13 +106,15 @@ Add to `claude_desktop_config.json`:
|
|
|
106
106
|
| SkillCorner | 51 | api-access, api-endpoints, data-model, physical-data, coordinate-system, concepts, identity-surfaces |
|
|
107
107
|
| Free sources | 45 | overview, fbref, understat |
|
|
108
108
|
| soccerdata | 40 | overview, data-sources, usage |
|
|
109
|
+
| TransferRoom | 38 | api-access, api-endpoints, data-model, identity-surfaces |
|
|
109
110
|
| Opta | 36 | event-types, qualifiers, coordinate-system, api-access, identity-surfaces |
|
|
111
|
+
| FMDB Pro | 36 | api-access, api-endpoints, data-model, identity-surfaces |
|
|
110
112
|
| socceraction | 26 | SPADL format, VAEP, Expected Threat |
|
|
111
113
|
| FotMob | 7 | identity-surfaces |
|
|
112
114
|
| Soccerdonna | 7 | identity-surfaces |
|
|
113
115
|
| Transfermarkt | 7 | identity-surfaces |
|
|
114
116
|
|
|
115
|
-
**
|
|
117
|
+
**1,042 searchable chunks** across 17 providers and tools.
|
|
116
118
|
|
|
117
119
|
## Contributing
|
|
118
120
|
|
package/data/docs.db
CHANGED
|
Binary file
|
|
@@ -0,0 +1,120 @@
|
|
|
1
|
+
---
|
|
2
|
+
source_url: https://api.fmdb.pro/api/openapi
|
|
3
|
+
source_type: crawled
|
|
4
|
+
upstream_version: latest (full OpenAPI)
|
|
5
|
+
crawled_at: 2026-07-09
|
|
6
|
+
---
|
|
7
|
+
|
|
8
|
+
# FMDB Pro API Access
|
|
9
|
+
|
|
10
|
+
## Overview
|
|
11
|
+
|
|
12
|
+
FMDB Pro is a commercial football database from Sports Interactive. The API exposes football entities and scouting-oriented fields for clubs, players, people, competitions, nations, countries, officials, stadiums, player appearances, historical player values, coverage, formations, and kit SVGs.
|
|
13
|
+
|
|
14
|
+
- Documentation UI: `https://app.fmdb.pro/docs`
|
|
15
|
+
- OpenAPI endpoint: `https://api.fmdb.pro/api/openapi`
|
|
16
|
+
- Base URL: `https://api.fmdb.pro/`
|
|
17
|
+
- Main API namespace: `/api/...`
|
|
18
|
+
- Local OpenAPI snapshot: `specs/fmdb-pro/openapi.json`
|
|
19
|
+
- OpenAPI version: `3.0.2`
|
|
20
|
+
- API version in the snapshot: `latest`
|
|
21
|
+
- Documentation variant in the snapshot: `full`
|
|
22
|
+
|
|
23
|
+
## Authentication
|
|
24
|
+
|
|
25
|
+
Requests use an API key in the `x-api-key` request header:
|
|
26
|
+
|
|
27
|
+
```http
|
|
28
|
+
GET /api/players?pageSize=20 HTTP/1.1
|
|
29
|
+
Host: api.fmdb.pro
|
|
30
|
+
x-api-key: <api-key>
|
|
31
|
+
```
|
|
32
|
+
|
|
33
|
+
The OpenAPI spec says API keys are issued by the FMDB Pro team. Do not put the key in query parameters or request bodies.
|
|
34
|
+
|
|
35
|
+
## API versioning
|
|
36
|
+
|
|
37
|
+
Data requests accept an optional `x-api-version` header. If omitted, the API returns the latest version. The documentation UI also exposes available API versions through `/api/status`, and the OpenAPI route accepts the version header when fetching a spec.
|
|
38
|
+
|
|
39
|
+
```http
|
|
40
|
+
GET /api/clubs HTTP/1.1
|
|
41
|
+
Host: api.fmdb.pro
|
|
42
|
+
x-api-key: <api-key>
|
|
43
|
+
x-api-version: latest
|
|
44
|
+
```
|
|
45
|
+
|
|
46
|
+
## OpenAPI variants
|
|
47
|
+
|
|
48
|
+
The OpenAPI route supports documentation variants:
|
|
49
|
+
|
|
50
|
+
- `version=simple` gives a smaller spec.
|
|
51
|
+
- `version=full` includes the full parameter lists for the data endpoints.
|
|
52
|
+
- `documentationType=redoc` or `documentationType=swagger` controls the UI-oriented spec rendering.
|
|
53
|
+
|
|
54
|
+
The downloaded snapshot in this repository is the `full` variant, which is useful for seeing every field-specific filter, sort, include, and exclude parameter. It is large because the player and person endpoints expose deeply nested fields.
|
|
55
|
+
|
|
56
|
+
## Response envelope
|
|
57
|
+
|
|
58
|
+
Search/list endpoints return JSON with a `meta` object and a `data` array. `meta` can include:
|
|
59
|
+
|
|
60
|
+
| Field | Meaning |
|
|
61
|
+
|---|---|
|
|
62
|
+
| `calledApiUrl` | URL called by the API layer. |
|
|
63
|
+
| `numTotalRecords` | Total records matching the request. |
|
|
64
|
+
| `currentPageSize` | Page size for page-number pagination. |
|
|
65
|
+
| `currentPage` | Current page number when using page pagination. |
|
|
66
|
+
| `totalPages` | Total pages when available. |
|
|
67
|
+
| `continuationToken` | Cursor token for the next continuation request. |
|
|
68
|
+
| `hasMoreResults` | Whether more cursor results are available. |
|
|
69
|
+
| `message` | Optional status or informational message. |
|
|
70
|
+
|
|
71
|
+
## Pagination
|
|
72
|
+
|
|
73
|
+
Two pagination styles are available:
|
|
74
|
+
|
|
75
|
+
| Parameter | Default | Notes |
|
|
76
|
+
|---|---:|---|
|
|
77
|
+
| `pageSize` | `20` | Number of records per request. The documented maximum is 500. |
|
|
78
|
+
| `page` | `1` | Page-number pagination. Do not combine with `continuation` or `continuationToken`. |
|
|
79
|
+
| `continuation` | `false` | Enables cursor pagination for larger extracts. |
|
|
80
|
+
| `continuationToken` | `null` | Cursor returned from the previous response. Requires `continuation=true`. |
|
|
81
|
+
|
|
82
|
+
For large extracts, prefer `continuation=true` and repeat with `continuationToken` until the response token is `null` or `hasMoreResults` is false. The spec notes that continuation mode does not work with `pageSize`; the API chooses an optimal result size for the dataset.
|
|
83
|
+
|
|
84
|
+
## Sorting and shaping
|
|
85
|
+
|
|
86
|
+
Use `sortBy` and `sortOrder` for sorting. Multiple comma-separated fields are supported, and `sortOrder` can also be comma-separated:
|
|
87
|
+
|
|
88
|
+
```http
|
|
89
|
+
GET /api/players?sortBy=name,age&sortOrder=ASC,DESC
|
|
90
|
+
```
|
|
91
|
+
|
|
92
|
+
Sorting cannot be used with continuation pagination.
|
|
93
|
+
|
|
94
|
+
Use `includeFields` or `excludeFields` to shape first-level response fields:
|
|
95
|
+
|
|
96
|
+
```http
|
|
97
|
+
GET /api/players?includeFields=id,name,dateOfBirth,fmId,externalIds
|
|
98
|
+
GET /api/clubs?excludeFields=kits,finances,wageHistory
|
|
99
|
+
```
|
|
100
|
+
|
|
101
|
+
Field shaping applies only to first-level fields, not nested objects.
|
|
102
|
+
|
|
103
|
+
## Filtering
|
|
104
|
+
|
|
105
|
+
The API supports exact-match filters by field name and a family of suffix operators:
|
|
106
|
+
|
|
107
|
+
| Filter form | Use |
|
|
108
|
+
|---|---|
|
|
109
|
+
| `<field>` | Exact match. |
|
|
110
|
+
| `<field>Null`, `<field>NotNull` | Null checks. |
|
|
111
|
+
| `<field>Not` | Negated exact match. |
|
|
112
|
+
| `<field>In`, `<field>NotIn` | List membership. |
|
|
113
|
+
| `<field>StartsWith`, `<field>EndsWith`, `<field>Contains` | String matching. |
|
|
114
|
+
| `<field>Regex` | Perl-style regular expression matching. |
|
|
115
|
+
| `<field>MinorThan`, `<field>MinorEqualThan` | Less-than comparisons; aliases of before-style date filters. |
|
|
116
|
+
| `<field>MajorThan`, `<field>MajorEqualThan` | Greater-than comparisons; aliases of after-style date filters. |
|
|
117
|
+
| `<field>Between`, `<field>BetweenIncluded` | Range comparisons using `lower|upper`. |
|
|
118
|
+
|
|
119
|
+
Nested fields use dot notation where listed by the full spec, for example `country.name`, `basedClub.id`, `externalIds.hudlWyscoutId`, or `gbe.status`.
|
|
120
|
+
|
|
@@ -0,0 +1,123 @@
|
|
|
1
|
+
---
|
|
2
|
+
source_url: https://api.fmdb.pro/api/openapi
|
|
3
|
+
source_type: crawled
|
|
4
|
+
upstream_version: latest (full OpenAPI)
|
|
5
|
+
crawled_at: 2026-07-09
|
|
6
|
+
---
|
|
7
|
+
|
|
8
|
+
# FMDB Pro API Endpoints
|
|
9
|
+
|
|
10
|
+
## Endpoint inventory
|
|
11
|
+
|
|
12
|
+
All endpoints are under `https://api.fmdb.pro/`. Data endpoints require `x-api-key`; most data requests also accept the optional `x-api-version` header.
|
|
13
|
+
|
|
14
|
+
| Method | Path | Description |
|
|
15
|
+
|---|---|---|
|
|
16
|
+
| `GET` | `/api/clubs` | List of clubs. |
|
|
17
|
+
| `GET` | `/api/clubsCompetitions` | List of club competitions. |
|
|
18
|
+
| `GET` | `/api/continents` | List of continents. |
|
|
19
|
+
| `GET` | `/api/countries` | List of countries. |
|
|
20
|
+
| `GET` | `/api/coverage` | Coverage information. |
|
|
21
|
+
| `GET` | `/api/formations` | List of formations. |
|
|
22
|
+
| `GET` | `/api/historicalValues` | Historical values of players. |
|
|
23
|
+
| `GET` | `/api/kit/{encryptedKey}.svg` | Kit SVG by unique hash from a club or nation `kits` node. |
|
|
24
|
+
| `GET` | `/api/nationPlayerAppearances` | Player appearances for a nation in the last 12 months. |
|
|
25
|
+
| `GET` | `/api/nations` | List of nations. |
|
|
26
|
+
| `GET` | `/api/nationsCompetitions` | List of national competitions. |
|
|
27
|
+
| `GET` | `/api/officials` | List of officials. |
|
|
28
|
+
| `GET` | `/api/openapi` | OpenAPI JSON file for the API. |
|
|
29
|
+
| `GET` | `/api/persons` | List of people. |
|
|
30
|
+
| `POST` | `/api/persons` | People search using a filter-group request body. |
|
|
31
|
+
| `GET` | `/api/playerAppearances` | Player appearances broken down by season and team. |
|
|
32
|
+
| `GET` | `/api/players` | List of players. |
|
|
33
|
+
| `POST` | `/api/players` | Player search using a filter-group request body. |
|
|
34
|
+
| `GET` | `/api/regions` | List of world regions. |
|
|
35
|
+
| `GET` | `/api/stadiums` | List of stadiums. |
|
|
36
|
+
| `GET` | `/api/status` | System status and available API versions. |
|
|
37
|
+
|
|
38
|
+
## Core catalogue endpoints
|
|
39
|
+
|
|
40
|
+
The broad catalogue endpoints are:
|
|
41
|
+
|
|
42
|
+
- `/api/clubs`
|
|
43
|
+
- `/api/clubsCompetitions`
|
|
44
|
+
- `/api/nations`
|
|
45
|
+
- `/api/nationsCompetitions`
|
|
46
|
+
- `/api/countries`
|
|
47
|
+
- `/api/continents`
|
|
48
|
+
- `/api/regions`
|
|
49
|
+
- `/api/stadiums`
|
|
50
|
+
- `/api/officials`
|
|
51
|
+
- `/api/formations`
|
|
52
|
+
|
|
53
|
+
These are useful for building local dimension tables before querying player/person data. The club and nation objects include nested relationship surfaces such as competitions, countries, stadiums, captains, kits, teams, reputation, facilities, and update timestamps.
|
|
54
|
+
|
|
55
|
+
## Player and person endpoints
|
|
56
|
+
|
|
57
|
+
`/api/players` is the main player surface. It returns football-playing fields, attributes, values, club/nation relationships, contracts, injuries, history, preferred moves, positions, GBE fields, tags, and external IDs.
|
|
58
|
+
|
|
59
|
+
`/api/persons` is broader. It includes non-playing people and staff-oriented fields such as current job, coaching, management, medical, tactics, tendencies, preferred formations, qualification, reputation, and chairperson fields, while sharing many identity and contract fields with players.
|
|
60
|
+
|
|
61
|
+
Both endpoints support:
|
|
62
|
+
|
|
63
|
+
- `GET` query-parameter search.
|
|
64
|
+
- `POST` body search using `RequestBodyPlayersFilterGroup` or `RequestBodyPersonsFilterGroup`.
|
|
65
|
+
- Page or continuation pagination.
|
|
66
|
+
- Sorting, field inclusion, field exclusion, and field-specific filters.
|
|
67
|
+
|
|
68
|
+
## Appearances and values
|
|
69
|
+
|
|
70
|
+
`/api/playerAppearances` returns season/team appearance aggregates with:
|
|
71
|
+
|
|
72
|
+
- `playerId`
|
|
73
|
+
- `playerName`
|
|
74
|
+
- `teamName`
|
|
75
|
+
- `competitionName`
|
|
76
|
+
- `competitionType`
|
|
77
|
+
- `season`
|
|
78
|
+
- `startDate`
|
|
79
|
+
- `endDate`
|
|
80
|
+
- `matches`
|
|
81
|
+
- `appearances`
|
|
82
|
+
- `starts`
|
|
83
|
+
- `minutesPlayed`
|
|
84
|
+
- `goals`
|
|
85
|
+
- `assists`
|
|
86
|
+
- `yellowCards`
|
|
87
|
+
- `redCards`
|
|
88
|
+
- `updated`
|
|
89
|
+
|
|
90
|
+
`/api/nationPlayerAppearances` returns national-team appearance information for the last 12 months.
|
|
91
|
+
|
|
92
|
+
`/api/historicalValues` returns historical player value records keyed by `type` and `typeId`, with `values`, `trends`, `currentTrend`, `dateOfBirth`, `lastChange`, and `updated`.
|
|
93
|
+
|
|
94
|
+
## Coverage and metadata
|
|
95
|
+
|
|
96
|
+
`/api/coverage` reports coverage by country/nation/club competition and includes count objects and game type. Use it to decide whether a requested country, nation, competition, or free-agent slice is covered before running wider extracts.
|
|
97
|
+
|
|
98
|
+
`/api/status` exposes system status and available API versions. The documentation UI uses it to populate the API-version selector.
|
|
99
|
+
|
|
100
|
+
`/api/openapi` returns the API specification. Useful query parameters include:
|
|
101
|
+
|
|
102
|
+
| Parameter | Notes |
|
|
103
|
+
|---|---|
|
|
104
|
+
| `version` | `simple` or `full`. |
|
|
105
|
+
| `documentationType` | `redoc` or `swagger`. |
|
|
106
|
+
|
|
107
|
+
## Kit SVGs
|
|
108
|
+
|
|
109
|
+
`/api/kit/{encryptedKey}.svg` returns a kit image by encrypted key. The key comes from a `kits` node in a Club or Nation object. Treat this as an asset endpoint rather than a searchable data endpoint.
|
|
110
|
+
|
|
111
|
+
## Common errors
|
|
112
|
+
|
|
113
|
+
The OpenAPI spec defines shared response references for:
|
|
114
|
+
|
|
115
|
+
| Response | Meaning |
|
|
116
|
+
|---|---|
|
|
117
|
+
| `400 BadRequest` | Request is malformed. |
|
|
118
|
+
| `401 Unauthorized` | Missing or invalid authentication. |
|
|
119
|
+
| `403 Forbidden` | API key lacks access to the requested resource. |
|
|
120
|
+
| `404 NotFound` | Requested resource does not exist. |
|
|
121
|
+
| `409 Conflict` | Similar entity already exists and cannot be duplicated. |
|
|
122
|
+
| `422 InvalidInput` | Entity constraints failed; response includes invalid fields/checks. |
|
|
123
|
+
|
|
@@ -0,0 +1,124 @@
|
|
|
1
|
+
---
|
|
2
|
+
source_url: https://api.fmdb.pro/api/openapi
|
|
3
|
+
source_type: crawled
|
|
4
|
+
upstream_version: latest (full OpenAPI)
|
|
5
|
+
crawled_at: 2026-07-09
|
|
6
|
+
---
|
|
7
|
+
|
|
8
|
+
# FMDB Pro Data Model
|
|
9
|
+
|
|
10
|
+
## Entity families
|
|
11
|
+
|
|
12
|
+
FMDB Pro is entity-first rather than match-event-first. The OpenAPI spec exposes these major families:
|
|
13
|
+
|
|
14
|
+
| Family | Main endpoints | Notes |
|
|
15
|
+
|---|---|---|
|
|
16
|
+
| Players and people | `/api/players`, `/api/persons` | Player/person identity, attributes, contracts, career history, values, availability, GBE fields, and external IDs. |
|
|
17
|
+
| Clubs and competitions | `/api/clubs`, `/api/clubsCompetitions` | Club metadata, competitions, stadiums, kits, reputation, facilities, finances, rules, and squad constraints. |
|
|
18
|
+
| Nations and geography | `/api/nations`, `/api/nationsCompetitions`, `/api/countries`, `/api/continents`, `/api/regions` | International-team, country, continent, region, and competition geography. |
|
|
19
|
+
| Staff and officials | `/api/persons`, `/api/officials` | Non-playing people, staff attributes, officials, categories, and reputation fields. |
|
|
20
|
+
| Performance summaries | `/api/playerAppearances`, `/api/nationPlayerAppearances` | Season/team aggregates, national appearances, and last-12-month nation appearance data. |
|
|
21
|
+
| Values | `/api/historicalValues` | Historical player value trends. |
|
|
22
|
+
| Coverage and docs | `/api/coverage`, `/api/status`, `/api/openapi` | Coverage discovery, version discovery, and machine-readable documentation. |
|
|
23
|
+
| Assets | `/api/kit/{encryptedKey}.svg` | Kit SVG retrieval from encrypted kit keys. |
|
|
24
|
+
|
|
25
|
+
## Player object
|
|
26
|
+
|
|
27
|
+
The `Players` response is the richest entity surface. Important first-level fields include:
|
|
28
|
+
|
|
29
|
+
| Area | Fields |
|
|
30
|
+
|---|---|
|
|
31
|
+
| Identity | `id`, `faId`, `fmId`, `externalIds`, `name`, `firstName`, `secondName`, `commonName`, `fullName`, `kitName`, `nickName`, `dateOfBirth`, `latestDateOfBirth`, `yearOfBirth`, `sex`. |
|
|
32
|
+
| Nationality and place | `country`, `nationalityInfo`, `secondCountry`, `thirdCountry`, `declaredNation`, `residentNation`, `cityOfBirth`, `regionOfBirth`. |
|
|
33
|
+
| Club state | `basedClub`, `permanentClub`, `loanClub`, `clubCompetition`, `clubNation`, `contractedNation`, `inBasedClubFirstTeam`. |
|
|
34
|
+
| Contracts | `permanentClubContractId`, `loanClubContractId`, `permanentClubContract`, `loanClubContract`, `clubContracts`, `nationContracts`. |
|
|
35
|
+
| Ability and roles | `currentAbility`, `recommendedCurrentAbility`, `potentialAbility`, `expectedPotentialAbility`, `position`, `positions`, `bestPosition`, `bestPositions`, `bestRole`. |
|
|
36
|
+
| Attributes | `mentalTraits`, `mentalAttributes`, `physicalAttributes`, `technicalAttributes`, `goalkeeperAttributes`, plus percentile groups for each. |
|
|
37
|
+
| Value and availability | `estimatedPlayerValues`, `availabilityIntelligence`, `injuries`, `unavailabilities`, `history`, `moves`, `retirements`. |
|
|
38
|
+
| Regulatory/scouting | `gbe`, `tags`, `homegrownStatus`, `clubCompetitionExperience`, `reputation`. |
|
|
39
|
+
|
|
40
|
+
Use `includeFields` aggressively when fetching players, because a full player object can be wide and deeply nested.
|
|
41
|
+
|
|
42
|
+
## Person object
|
|
43
|
+
|
|
44
|
+
The `Persons` response overlaps with players but is broader for staff and non-playing people. It includes identity, nationality, club/nation relationships, contracts, histories, GBE fields, and reputation, plus staff-specific fields:
|
|
45
|
+
|
|
46
|
+
- `currentJob`
|
|
47
|
+
- `coaching`
|
|
48
|
+
- `coachingStyle`
|
|
49
|
+
- `dataAnalyst`
|
|
50
|
+
- `knowledge`
|
|
51
|
+
- `management`
|
|
52
|
+
- `medical`
|
|
53
|
+
- `qualification`
|
|
54
|
+
- `preferredFormations`
|
|
55
|
+
- `preferredRolesInPossession`
|
|
56
|
+
- `preferredRolesOutOfPossession`
|
|
57
|
+
- `preferredTactics`
|
|
58
|
+
- `tacticalTendencies`
|
|
59
|
+
- `tactics`
|
|
60
|
+
- `tendencies`
|
|
61
|
+
- `chairperson`
|
|
62
|
+
|
|
63
|
+
Use `/api/persons` when the target can be a coach, scout, official-like staff member, director, or other non-playing football person. Use `/api/players` when the target should have player-specific fields such as positions, playing attributes, preferred moves, player values, and playing career history.
|
|
64
|
+
|
|
65
|
+
## Club object
|
|
66
|
+
|
|
67
|
+
The `Clubs` response includes:
|
|
68
|
+
|
|
69
|
+
- Identity fields: `id`, `faId`, `fmId`, `name`, `officialName`, `nameShort`, `officialThreeLetterName`, `city`, `country`.
|
|
70
|
+
- Competition and squad state: `competition`, `lastCompetition`, `regionalDivision`, `teams`, `playerCount`.
|
|
71
|
+
- Facilities and stadiums: `stadium`, `reserveStadium`, `youthStadium`, `trainingGround`, `trainingFacilities`.
|
|
72
|
+
- People relationships: `captain`, `viceCaptain`, `chairmanTitle`.
|
|
73
|
+
- Commercial and operational fields: `finances`, `income`, `wageHistory`, `reputation`, `potentialReputation`, `professionalStatus`.
|
|
74
|
+
- Presentation and assets: `kits`, `currentKit`, `genericLogoId`, colours, hashtags, and nicknames.
|
|
75
|
+
|
|
76
|
+
## Nation and competition objects
|
|
77
|
+
|
|
78
|
+
Nations include national-team and football-governance fields such as:
|
|
79
|
+
|
|
80
|
+
- `id`, `fmId`, `name`, `nameThreeLetter`, `internationalCode`
|
|
81
|
+
- `country`, `continent`, `footballingContinent`, `footballingRegion`, `worldRegion`
|
|
82
|
+
- `nationalTeamStadium`, `captain`, `viceCaptain`, `kits`
|
|
83
|
+
- `fifaCoefficient`, `fifaFullMember`, `reputation`, `youthRating`
|
|
84
|
+
- `gameImportance`, `leagueStandard`, `seasonTypeId`
|
|
85
|
+
|
|
86
|
+
Club and nation competition endpoints expose competition identity, host/geography, colours, age limits, trophy and pitch flags, reputation, VAR/goal-line flags, squads/teams, rules, and GBE-related bands where applicable.
|
|
87
|
+
|
|
88
|
+
## Attribute and percentile groups
|
|
89
|
+
|
|
90
|
+
Player technical, mental, physical, goalkeeper, and mental-trait attributes use Football Manager-style names such as:
|
|
91
|
+
|
|
92
|
+
- Technical: `corners`, `crossing`, `dribbling`, `finishing`, `firstTouch`, `freeKicks`, `heading`, `longShots`, `longThrows`, `marking`, `passing`, `penalties`, `tackling`, `technique`, `versatility`.
|
|
93
|
+
- Mental: `aggression`, `anticipation`, `bravery`, `composure`, `concentration`, `consistency`, `decisions`, `flair`, `importantMatches`, `leadership`, `offTheBall`, `positioning`, `teamWork`, `vision`, `workRate`.
|
|
94
|
+
- Physical: `acceleration`, `agility`, `balance`, `jumpingReach`, `naturalFitness`, `pace`, `stamina`, `strength`.
|
|
95
|
+
- Goalkeeper: `aerialAbility`, `commandOfArea`, `communication`, `gkEccentricity`, `handling`, `kicking`, `oneOnOnes`, `reflexes`, `rushingOut`, `tendencyToPunch`, `throwing`.
|
|
96
|
+
|
|
97
|
+
Percentile groups repeat many of these names with comparison scopes such as absolute, by age, by role, by league, and by league role.
|
|
98
|
+
|
|
99
|
+
## GBE fields
|
|
100
|
+
|
|
101
|
+
Player and person surfaces can include a `gbe` object. The player full spec exposes fields such as:
|
|
102
|
+
|
|
103
|
+
- `gbe.status`
|
|
104
|
+
- `gbe.exemptionReason`
|
|
105
|
+
- `gbe.qualified`
|
|
106
|
+
- `gbe.qualifiedOrPanel`
|
|
107
|
+
- `gbe.accuracy.level`
|
|
108
|
+
- `gbe.accuracy.percentage`
|
|
109
|
+
- `gbe.detail.status.totalPoints`
|
|
110
|
+
- `gbe.detail.status.maxPoints`
|
|
111
|
+
- `gbe.detail.status.outcome`
|
|
112
|
+
- `gbe.detail.status.pointsBreakdown.*`
|
|
113
|
+
- `gbe.detail.internationalAppearances.*`
|
|
114
|
+
- `gbe.detail.domesticMinutes.*`
|
|
115
|
+
- `gbe.detail.continentalMinutes.*`
|
|
116
|
+
- `gbe.detail.lastClub.*`
|
|
117
|
+
- `gbe.detail.currentClub.*`
|
|
118
|
+
|
|
119
|
+
These fields are useful for UK Governing Body Endorsement checks and scouting workflows. Treat them as derived policy/scouting fields rather than raw match-event data.
|
|
120
|
+
|
|
121
|
+
## Update timestamps
|
|
122
|
+
|
|
123
|
+
Most response objects include an `updated` field. The OpenAPI spec documents field-level filters for `updated`, so local mirrors can query changed entities by date/time comparison. There is no separate update-feed endpoint in the current spec; use endpoint-level `updated` filters plus continuation pagination for synchronisation.
|
|
124
|
+
|
|
@@ -0,0 +1,123 @@
|
|
|
1
|
+
---
|
|
2
|
+
source_url: https://api.fmdb.pro/api/openapi
|
|
3
|
+
source_type: crawled
|
|
4
|
+
upstream_version: latest (full OpenAPI)
|
|
5
|
+
crawled_at: 2026-07-09
|
|
6
|
+
---
|
|
7
|
+
|
|
8
|
+
# FMDB Pro Identity Surfaces
|
|
9
|
+
|
|
10
|
+
## Primary entity IDs
|
|
11
|
+
|
|
12
|
+
FMDB Pro entities expose an `id` field. Treat it as the FMDB Pro primary key for the returned entity type:
|
|
13
|
+
|
|
14
|
+
- `/api/players` -> player `id`
|
|
15
|
+
- `/api/persons` -> person `id`
|
|
16
|
+
- `/api/clubs` -> club `id`
|
|
17
|
+
- `/api/nations` -> nation `id`
|
|
18
|
+
- `/api/clubsCompetitions` and `/api/nationsCompetitions` -> competition `id`
|
|
19
|
+
- `/api/stadiums` -> stadium `id`
|
|
20
|
+
- `/api/officials` -> official `id`
|
|
21
|
+
|
|
22
|
+
Do not assume IDs are globally unique across entity types unless FMDB Pro explicitly confirms that. Store provider keys with an entity-type namespace, for example `fmdb-pro:player:<id>` and `fmdb-pro:club:<id>`.
|
|
23
|
+
|
|
24
|
+
## Football Manager IDs
|
|
25
|
+
|
|
26
|
+
Many entities include `fmId`. This is an important bridge field because FMDB Pro is built around Sports Interactive's football database. Ingest it separately from the FMDB Pro API `id`:
|
|
27
|
+
|
|
28
|
+
| Field | Use |
|
|
29
|
+
|---|---|
|
|
30
|
+
| `id` | FMDB Pro API entity key. |
|
|
31
|
+
| `fmId` | Football Manager database identity where present. |
|
|
32
|
+
|
|
33
|
+
For person matching, prefer a composite candidate set using `fmId`, name fields, date/year of birth, nationality, and club context. Do not collapse `id` and `fmId` into one namespace.
|
|
34
|
+
|
|
35
|
+
## FA IDs
|
|
36
|
+
|
|
37
|
+
The player, person, and club surfaces can include `faId`. This can be useful for England/FA-facing workflows, but coverage and semantics may vary by entity type. Treat it as an external identifier with nullable/partial coverage.
|
|
38
|
+
|
|
39
|
+
## External IDs
|
|
40
|
+
|
|
41
|
+
The player full spec exposes `externalIds`, including `externalIds.hudlWyscoutId` as a filterable nested field. This is the clearest documented cross-provider bridge in the current OpenAPI snapshot.
|
|
42
|
+
|
|
43
|
+
Use external IDs as high-confidence links only when the field is present and the target provider namespace is explicit. For example:
|
|
44
|
+
|
|
45
|
+
```text
|
|
46
|
+
FMDB Pro player id -> externalIds.hudlWyscoutId -> Hudl/Wyscout player id
|
|
47
|
+
```
|
|
48
|
+
|
|
49
|
+
## Name and birth fields
|
|
50
|
+
|
|
51
|
+
Player/person identity includes multiple name and birth-date fields:
|
|
52
|
+
|
|
53
|
+
- `name`
|
|
54
|
+
- `firstName`
|
|
55
|
+
- `secondName`
|
|
56
|
+
- `commonName`
|
|
57
|
+
- `fullName`
|
|
58
|
+
- `kitName`
|
|
59
|
+
- `nickName`
|
|
60
|
+
- `dateOfBirth`
|
|
61
|
+
- `latestDateOfBirth`
|
|
62
|
+
- `yearOfBirth`
|
|
63
|
+
- `cityOfBirth`
|
|
64
|
+
- `regionOfBirth`
|
|
65
|
+
|
|
66
|
+
Use `dateOfBirth` when available. `latestDateOfBirth` and `yearOfBirth` are useful for uncertain or partial birth-date cases, but they should not be treated as equivalent to a confirmed date of birth.
|
|
67
|
+
|
|
68
|
+
## Nationality and country context
|
|
69
|
+
|
|
70
|
+
Player/person nationality and country context includes:
|
|
71
|
+
|
|
72
|
+
- `country`
|
|
73
|
+
- `nationalityInfo`
|
|
74
|
+
- `secondCountry`
|
|
75
|
+
- `secondNationalityInfo`
|
|
76
|
+
- `thirdCountry`
|
|
77
|
+
- `thirdNationalityInfo`
|
|
78
|
+
- `declaredNation`
|
|
79
|
+
- `residentNation`
|
|
80
|
+
- `basedCountry`
|
|
81
|
+
- `clubNation`
|
|
82
|
+
- `contractedNation`
|
|
83
|
+
|
|
84
|
+
For matching, distinguish legal nationality/country fields from declared sporting nation and current football location. `declaredNation`, `clubNation`, and `contractedNation` can be especially useful disambiguators, but they answer different questions.
|
|
85
|
+
|
|
86
|
+
## Club context
|
|
87
|
+
|
|
88
|
+
Current and historical club context appears through:
|
|
89
|
+
|
|
90
|
+
- `basedClub`
|
|
91
|
+
- `permanentClub`
|
|
92
|
+
- `loanClub`
|
|
93
|
+
- `lastPlayingClub`
|
|
94
|
+
- `lastNonPlayingClub`
|
|
95
|
+
- `clubCompetition`
|
|
96
|
+
- `permanentClubContract`
|
|
97
|
+
- `loanClubContract`
|
|
98
|
+
- `clubContracts`
|
|
99
|
+
- `history`
|
|
100
|
+
- `moves`
|
|
101
|
+
|
|
102
|
+
Use club context as supporting evidence, not as a durable identity key. Players and staff move, and loan/permanent relationships can coexist.
|
|
103
|
+
|
|
104
|
+
## Recommended matching approach
|
|
105
|
+
|
|
106
|
+
For players:
|
|
107
|
+
|
|
108
|
+
1. Match exact `fmId` or explicit external IDs first.
|
|
109
|
+
2. Then compare `id` within the FMDB Pro namespace.
|
|
110
|
+
3. Use `dateOfBirth`, `latestDateOfBirth`, or `yearOfBirth` as birth evidence.
|
|
111
|
+
4. Use `fullName`, `commonName`, `firstName`, `secondName`, and `kitName` as name evidence.
|
|
112
|
+
5. Use country/nation and club fields as disambiguators.
|
|
113
|
+
|
|
114
|
+
For staff/persons:
|
|
115
|
+
|
|
116
|
+
1. Match exact `fmId` first where present.
|
|
117
|
+
2. Use `id` in the person namespace.
|
|
118
|
+
3. Use name and birth evidence.
|
|
119
|
+
4. Use `currentJob`, club/nation relationships, coaching/tactics fields, and career history as context.
|
|
120
|
+
|
|
121
|
+
## Public-safe provenance
|
|
122
|
+
|
|
123
|
+
These identity notes are derived from the public FMDB Pro OpenAPI schema and documentation UI. They describe field surfaces and matching strategy only; they do not imply access to private FMDB Pro data, credentials, or a complete mapping table.
|
|
@@ -0,0 +1,91 @@
|
|
|
1
|
+
---
|
|
2
|
+
source_url: https://www.transferroom.com/api-docs
|
|
3
|
+
source_type: crawled
|
|
4
|
+
upstream_version: null
|
|
5
|
+
crawled_at: 2026-07-09
|
|
6
|
+
---
|
|
7
|
+
|
|
8
|
+
# TransferRoom API Access
|
|
9
|
+
|
|
10
|
+
## Overview
|
|
11
|
+
|
|
12
|
+
TransferRoom exposes a commercial club API for integrating transfer-market and recruitment data into internal club systems. The public documentation describes JSON endpoints for players, competitions, head coaches, teams, transfers, received pitches, requirements, and injury data.
|
|
13
|
+
|
|
14
|
+
- Public docs page: `https://www.transferroom.com/api-docs`
|
|
15
|
+
- Embedded docs app: `https://v0-simple-api-documentation-templat.vercel.app/`
|
|
16
|
+
- Contact/access page linked by the docs: `https://www.transferroom.com/features/club-api`
|
|
17
|
+
- Production API host shown in examples: `https://apiprod.transferroom.com`
|
|
18
|
+
- API namespace shown in examples: `/api/external/...`
|
|
19
|
+
|
|
20
|
+
The docs page says the API is intended to let clubs "extract TransferRoom's unique transfer market data" in JSON format for integration into internal databases.
|
|
21
|
+
|
|
22
|
+
## Access levels
|
|
23
|
+
|
|
24
|
+
Access is subscription-tier dependent and can also be bought standalone. The public docs describe three access groupings:
|
|
25
|
+
|
|
26
|
+
| Access level | Publicly documented data |
|
|
27
|
+
|---|---|
|
|
28
|
+
| Lite API | Basic player identifiers, xTV (Expected Transfer Value), agency information, and player rating. |
|
|
29
|
+
| Advanced API | All Lite features plus advanced player data, estimated salaries, contract information, GBE scores, head coach data, team data, transfer data, and pitches received on TransferRoom. |
|
|
30
|
+
| Advanced Injury Data | Injury data across 50 leagues, injury records across 25 data points, historical data back to 2017, recurrence risk, player injury risk rating, and fatigue/workload style metrics. |
|
|
31
|
+
|
|
32
|
+
Endpoint availability is tied to these access levels. For example, the public docs mark requirements and pitches as Advanced API endpoints, and injury endpoints as Advanced Injury Data endpoints.
|
|
33
|
+
|
|
34
|
+
## Authentication
|
|
35
|
+
|
|
36
|
+
The docs show a login call that returns a bearer token:
|
|
37
|
+
|
|
38
|
+
```python
|
|
39
|
+
import requests
|
|
40
|
+
|
|
41
|
+
email = "example@transferroom.com"
|
|
42
|
+
password = "example_p4ssW0rd"
|
|
43
|
+
|
|
44
|
+
auth_url = "https://apiprod.transferroom.com/api/external/login?email=" + email + "&password=" + password
|
|
45
|
+
response = requests.post(auth_url)
|
|
46
|
+
token = response.json()["token"]
|
|
47
|
+
```
|
|
48
|
+
|
|
49
|
+
Subsequent requests send the token in the `Authorization` header:
|
|
50
|
+
|
|
51
|
+
```python
|
|
52
|
+
headers = {"Authorization": "Bearer " + token}
|
|
53
|
+
response = requests.get(
|
|
54
|
+
"https://apiprod.transferroom.com/api/external/players?position=0&amount=100",
|
|
55
|
+
headers=headers,
|
|
56
|
+
)
|
|
57
|
+
```
|
|
58
|
+
|
|
59
|
+
Operational note: because the public example passes credentials as query parameters, avoid logging request URLs, reverse-proxy access logs, shell history, or monitoring traces that could capture the full login URL.
|
|
60
|
+
|
|
61
|
+
## Rate limits
|
|
62
|
+
|
|
63
|
+
The public docs state that requests are rate limited to **300 requests per minute across all endpoints**.
|
|
64
|
+
|
|
65
|
+
## Pagination
|
|
66
|
+
|
|
67
|
+
List endpoints shown in the docs use offset-style pagination:
|
|
68
|
+
|
|
69
|
+
| Parameter | Meaning |
|
|
70
|
+
|---|---|
|
|
71
|
+
| `position` | Starting point in the list. Defaults to `0` where documented. |
|
|
72
|
+
| `amount` | Number of results to return. Defaults to `1000` and maxes at `10000` where documented. |
|
|
73
|
+
|
|
74
|
+
The examples use `position=0&amount=100` or `position=0&amount=1000` for list extracts.
|
|
75
|
+
|
|
76
|
+
## Common request pattern
|
|
77
|
+
|
|
78
|
+
```python
|
|
79
|
+
import requests
|
|
80
|
+
|
|
81
|
+
headers = {"Authorization": "Bearer " + token}
|
|
82
|
+
|
|
83
|
+
request_url = "https://apiprod.transferroom.com/api/external/players?position=0&amount=100"
|
|
84
|
+
response = requests.get(request_url, headers=headers)
|
|
85
|
+
data = response.json()
|
|
86
|
+
```
|
|
87
|
+
|
|
88
|
+
## Public documentation limits
|
|
89
|
+
|
|
90
|
+
The public docs do not expose a downloadable OpenAPI/Swagger specification. Endpoint paths, examples, permissions, query parameters, rate limit, and sample response fields are visible, but exact error schemas, status codes, and full authentication contract are not described in the public page.
|
|
91
|
+
|
|
@@ -0,0 +1,257 @@
|
|
|
1
|
+
---
|
|
2
|
+
source_url: https://v0-simple-api-documentation-templat.vercel.app/
|
|
3
|
+
source_type: crawled
|
|
4
|
+
upstream_version: null
|
|
5
|
+
crawled_at: 2026-07-09
|
|
6
|
+
---
|
|
7
|
+
|
|
8
|
+
# TransferRoom API Endpoints
|
|
9
|
+
|
|
10
|
+
## Endpoint inventory
|
|
11
|
+
|
|
12
|
+
All endpoint examples use the base path `https://apiprod.transferroom.com/api/external`.
|
|
13
|
+
|
|
14
|
+
| Method | Path | Access | Description |
|
|
15
|
+
|---|---|---|---|
|
|
16
|
+
| `POST` | `/login` | API credentials | Returns a bearer token. |
|
|
17
|
+
| `GET` | `/competitions` | Documented API access | Returns competitions and team membership. |
|
|
18
|
+
| `GET` | `/players` | Lite API / Advanced API | Returns player identity, club, agency, value, rating, contract, GBE, and availability fields depending on access tier. |
|
|
19
|
+
| `GET` | `/coaches` | Advanced API | Returns head coach identity, career, contract, agency, rating, tactical, and team-impact fields. |
|
|
20
|
+
| `GET` | `/teams` | Advanced API | Returns team identity, competition, head coach, squad value, rating, and predicted requirement fields. |
|
|
21
|
+
| `GET` | `/transfers` | Advanced API | Returns player transfer movements and value-at-date fields. |
|
|
22
|
+
| `GET` | `/pitches` | Advanced API, club users only | Returns pitches and plus pitches received on TransferRoom. |
|
|
23
|
+
| `GET` | `/requirements` | Advanced API | Returns club recruitment requirements posted on TransferRoom. |
|
|
24
|
+
| `GET` | `/injuries/competitions` | Advanced Injury Data | Returns injury records by competition. |
|
|
25
|
+
| `GET` | `/injuries/players` | Advanced Injury Data | Returns player injury and predictive availability data. |
|
|
26
|
+
|
|
27
|
+
## Authentication endpoint
|
|
28
|
+
|
|
29
|
+
`POST /login`
|
|
30
|
+
|
|
31
|
+
Query parameters shown in the public example:
|
|
32
|
+
|
|
33
|
+
| Parameter | Type | Notes |
|
|
34
|
+
|---|---|---|
|
|
35
|
+
| `email` | string | TransferRoom account email. |
|
|
36
|
+
| `password` | string | TransferRoom account password. |
|
|
37
|
+
|
|
38
|
+
Sample success response:
|
|
39
|
+
|
|
40
|
+
```json
|
|
41
|
+
{
|
|
42
|
+
"token": "eyJhbGciOiJIUzI1NiIsInR5cCI6Ik..."
|
|
43
|
+
}
|
|
44
|
+
```
|
|
45
|
+
|
|
46
|
+
## Competitions
|
|
47
|
+
|
|
48
|
+
`GET /competitions`
|
|
49
|
+
|
|
50
|
+
Returns competition records. The public sample includes:
|
|
51
|
+
|
|
52
|
+
| Field | Meaning |
|
|
53
|
+
|---|---|
|
|
54
|
+
| `Id` | TransferRoom competition ID. |
|
|
55
|
+
| `CompetitionName` | Competition name. |
|
|
56
|
+
| `Country` | Competition country. |
|
|
57
|
+
| `DivisionLevel` | League/division level. |
|
|
58
|
+
| `Teams` | Team IDs in the competition. |
|
|
59
|
+
| `AvgTeamRating` | Average team rating. |
|
|
60
|
+
| `AvgStarterRating` | Average starter rating. |
|
|
61
|
+
|
|
62
|
+
## Players
|
|
63
|
+
|
|
64
|
+
`GET /players`
|
|
65
|
+
|
|
66
|
+
Common query parameters:
|
|
67
|
+
|
|
68
|
+
| Parameter | Type | Notes |
|
|
69
|
+
|---|---|---|
|
|
70
|
+
| `position` | integer | Starting point in list for pagination. |
|
|
71
|
+
| `amount` | integer | Number of results to return. |
|
|
72
|
+
| `playerid` | integer | Filter by TransferRoom player ID where available. |
|
|
73
|
+
| `myshortlist` | bit/string | Filter to players on your TransferRoom shortlists; docs show `true`. |
|
|
74
|
+
| `mysquad` | bit/string | Filter to players in your team; docs show `true`. |
|
|
75
|
+
|
|
76
|
+
Sample response fields include:
|
|
77
|
+
|
|
78
|
+
- `TR_ID`, `Name`, `BirthDate`
|
|
79
|
+
- `ParentTeamId`, `CurrentTeamId`, `ParentTeam`, `CurrentTeam`, `TeamHistory`
|
|
80
|
+
- `Country`, `CompetitionId`, `Competition`, `DivisionLevel`
|
|
81
|
+
- `Nationality1`, `Nationality2`
|
|
82
|
+
- `FirstPosition`, `SecondPosition`, `PlayingStyle`, `PreferredFoot`
|
|
83
|
+
- `ContractExpiry`
|
|
84
|
+
- `Agency`, `AgencyVerified`
|
|
85
|
+
- `Shortlisted`
|
|
86
|
+
- `CurrentClubRecentMinsPerc`
|
|
87
|
+
- `GBEScore`, `GBEResult`, `GBEIntAppPts`, `GBEDomMinsPts`, `GBEContMinsPts`, `GBELeaguePosPts`, `GBEContProgPts`, `GBELeagueStdPts`
|
|
88
|
+
- `xTV`, `xTVChange6mPerc`, `xTVChange12mPerc`, `xTVHistory`
|
|
89
|
+
- `BaseValue`, `BaseValueHistory`
|
|
90
|
+
- `EstimatedSalary`
|
|
91
|
+
- `Rating`, `Potential`
|
|
92
|
+
- `AvailableSale`, `AvailableAskingPrice`, `AvailableSellOn`, `AvailableLoan`, `AvailableMonthlyLoanFee`, `AvailableCurrency`
|
|
93
|
+
|
|
94
|
+
## Head coaches
|
|
95
|
+
|
|
96
|
+
`GET /coaches`
|
|
97
|
+
|
|
98
|
+
Common query parameters follow the same list pattern as players: `position`, `amount`, and coach-specific filters where enabled by account access.
|
|
99
|
+
|
|
100
|
+
Sample response fields include:
|
|
101
|
+
|
|
102
|
+
- `TR_ID`, `Name`, `BirthDate`
|
|
103
|
+
- `Nationality1`, `Nationality2`
|
|
104
|
+
- `CurrentTeam`, `CurrentRole`
|
|
105
|
+
- `CareerHistory`
|
|
106
|
+
- `Country`, `Competition`, `DivisionLevel`
|
|
107
|
+
- `PreviousTeam`, `ContractExpiry`
|
|
108
|
+
- `Agency`, `AgencyVerified`
|
|
109
|
+
- `Rating`, `RatingChange12m`
|
|
110
|
+
- `TacticalStyle`, `Suitability`, `TeamRatingImpact`
|
|
111
|
+
- `TrustInYouth`, `PreferredFormation`, `SquadRotation`
|
|
112
|
+
- `ThreeSeasonAvgSpend`
|
|
113
|
+
|
|
114
|
+
## Teams
|
|
115
|
+
|
|
116
|
+
`GET /teams`
|
|
117
|
+
|
|
118
|
+
Documented query parameter:
|
|
119
|
+
|
|
120
|
+
| Parameter | Type | Notes |
|
|
121
|
+
|---|---|---|
|
|
122
|
+
| `competitionid` | integer | Filter teams by competition ID. |
|
|
123
|
+
|
|
124
|
+
Sample response fields include:
|
|
125
|
+
|
|
126
|
+
- `TR_ID`
|
|
127
|
+
- `Team`
|
|
128
|
+
- `Country`
|
|
129
|
+
- `CompetitionId`
|
|
130
|
+
- `Competition`
|
|
131
|
+
- `CompetitionDivisionLevel`
|
|
132
|
+
- `HeadCoachID`
|
|
133
|
+
- `TotalxTV`
|
|
134
|
+
- `TotalBaseValue`
|
|
135
|
+
- `AverageStarterRating`
|
|
136
|
+
- `TeamRating`
|
|
137
|
+
- `TeamRatingHistory`
|
|
138
|
+
- `PredictedRequirements`
|
|
139
|
+
|
|
140
|
+
## Transfers
|
|
141
|
+
|
|
142
|
+
`GET /transfers`
|
|
143
|
+
|
|
144
|
+
Documented query parameter:
|
|
145
|
+
|
|
146
|
+
| Parameter | Type | Notes |
|
|
147
|
+
|---|---|---|
|
|
148
|
+
| `competitionid` | integer | Filter transfers by competition ID. |
|
|
149
|
+
|
|
150
|
+
Sample response fields include:
|
|
151
|
+
|
|
152
|
+
- `PlayerId`, `Player`
|
|
153
|
+
- `FromTeamId`, `FromTeam`
|
|
154
|
+
- `ToTeamId`, `ToTeam`
|
|
155
|
+
- `Date`
|
|
156
|
+
- `TransferType`
|
|
157
|
+
- `TransferFee`
|
|
158
|
+
- `xTVatDate`
|
|
159
|
+
- `xTVatEnd`
|
|
160
|
+
|
|
161
|
+
## Pitches
|
|
162
|
+
|
|
163
|
+
`GET /pitches`
|
|
164
|
+
|
|
165
|
+
The public docs describe this as a club-user endpoint that returns pitches and plus pitches received on TransferRoom.
|
|
166
|
+
|
|
167
|
+
Sample response fields include:
|
|
168
|
+
|
|
169
|
+
- `PitchType`
|
|
170
|
+
- `RequirementID`
|
|
171
|
+
- `Player`, `PlayerId`
|
|
172
|
+
- `HeadCoach`, `HeadCoachId`
|
|
173
|
+
- `PitchDate`
|
|
174
|
+
- `PitchedByTeam`, `PitchedByTeamID`
|
|
175
|
+
- `PitchedByAgency`, `PitchedByAgencyID`
|
|
176
|
+
- `PitchCurrency`
|
|
177
|
+
- `PitchTransferFee`
|
|
178
|
+
- `PitchGrossAnnualSalary`
|
|
179
|
+
- `PitchLoanFee`
|
|
180
|
+
- `PitchSellOnPerc`
|
|
181
|
+
- `PitchMessage`
|
|
182
|
+
- `PitchStatus`
|
|
183
|
+
|
|
184
|
+
## Requirements
|
|
185
|
+
|
|
186
|
+
`GET /requirements`
|
|
187
|
+
|
|
188
|
+
Returns recruitment requirements posted on TransferRoom.
|
|
189
|
+
|
|
190
|
+
Sample response fields include:
|
|
191
|
+
|
|
192
|
+
- `TR_ID`
|
|
193
|
+
- `Active`
|
|
194
|
+
- `UpdatedAt`
|
|
195
|
+
- `TransferType`
|
|
196
|
+
- `Position`
|
|
197
|
+
- `Foot`
|
|
198
|
+
- `PlayingStyle`
|
|
199
|
+
- `PreferredNationality`
|
|
200
|
+
- `FromAge`, `ToAge`
|
|
201
|
+
- `MinHeight`
|
|
202
|
+
- `TransferFee`
|
|
203
|
+
- `GrossAnnualSalary`
|
|
204
|
+
- `MonthlyLoanFee`
|
|
205
|
+
|
|
206
|
+
## Injuries by competition
|
|
207
|
+
|
|
208
|
+
`GET /injuries/competitions`
|
|
209
|
+
|
|
210
|
+
Query parameters:
|
|
211
|
+
|
|
212
|
+
| Parameter | Type | Required | Notes |
|
|
213
|
+
|---|---|---|---|
|
|
214
|
+
| `competitionid` | integer | yes | Filter by competition ID. |
|
|
215
|
+
| `seasonstartyear` | integer | no | Filter to a specific season. |
|
|
216
|
+
|
|
217
|
+
Sample response fields include:
|
|
218
|
+
|
|
219
|
+
- `TR_ID`, `Name`
|
|
220
|
+
- `TeamId`, `Team`
|
|
221
|
+
- `CompetitionId`, `Competition`, `DivisionLevel`, `Country`
|
|
222
|
+
- `Injury`, `BodyPart`, `InjuryType`
|
|
223
|
+
- `StartDate`, `ReturnDate`, `DaysOut`, `MatchesMissed`, `ExpectedReturnDate`
|
|
224
|
+
- `Training`, `SurgeryRequired`, `Recurrence`
|
|
225
|
+
- `EventDescription`, `PrognosisDescription`
|
|
226
|
+
- `Source_1`, `Source_2`, `Source_3`
|
|
227
|
+
- `InjuryAverageLengthDays`, `InjuryMedianLength`, `InjuryLowerQuartileLength`, `InjuryUpperQuartileLength`
|
|
228
|
+
- `TwoYearOccurenceRate`, `TwoYearRecurrenceRate`, `IncreasedTwoYearRecurranceRisk`
|
|
229
|
+
|
|
230
|
+
The field names above preserve the public documentation spelling, including `Occurence` and `Recurrance`.
|
|
231
|
+
|
|
232
|
+
## Injuries by player
|
|
233
|
+
|
|
234
|
+
`GET /injuries/players`
|
|
235
|
+
|
|
236
|
+
Query parameters:
|
|
237
|
+
|
|
238
|
+
| Parameter | Type | Notes |
|
|
239
|
+
|---|---|---|
|
|
240
|
+
| `position` | integer | Starting point in list for pagination. |
|
|
241
|
+
| `amount` | integer | Number of results to return. |
|
|
242
|
+
| `playerid` | integer | Filter by player ID. |
|
|
243
|
+
| `myshortlist` | bit/string | Filter to players on your TransferRoom shortlists; docs show `true`. |
|
|
244
|
+
| `mysquad` | bit/string | Filter to players in your team; docs show `true`. |
|
|
245
|
+
|
|
246
|
+
Sample response fields include:
|
|
247
|
+
|
|
248
|
+
- `TR_ID`, `Name`, `BirthDate`
|
|
249
|
+
- `MatchesMissed5yrsPercentage`
|
|
250
|
+
- `TotalMins3Months`, `MinsPlayed3MonthsPercentile`
|
|
251
|
+
- `TotalMins6Months`, `MinsPlayed6MonthsPercentile`
|
|
252
|
+
- `TotalMins12Months`, `MinsPlayed12MonthsPercentile`
|
|
253
|
+
- `InjuryRiskRating`
|
|
254
|
+
- `xAvailability`
|
|
255
|
+
- `CurrentWorkload`
|
|
256
|
+
- `PlayerInjuries`
|
|
257
|
+
|
|
@@ -0,0 +1,143 @@
|
|
|
1
|
+
---
|
|
2
|
+
source_url: https://v0-simple-api-documentation-templat.vercel.app/
|
|
3
|
+
source_type: crawled
|
|
4
|
+
upstream_version: null
|
|
5
|
+
crawled_at: 2026-07-09
|
|
6
|
+
---
|
|
7
|
+
|
|
8
|
+
# TransferRoom Data Model
|
|
9
|
+
|
|
10
|
+
## Entity families
|
|
11
|
+
|
|
12
|
+
TransferRoom's public API docs show a recruitment and transfer-market data model rather than an event-data or tracking-data model.
|
|
13
|
+
|
|
14
|
+
| Family | Endpoint | Main use |
|
|
15
|
+
|---|---|---|
|
|
16
|
+
| Competitions | `/competitions` | Competition IDs, country, division level, team membership, and average ratings. |
|
|
17
|
+
| Players | `/players` | Player identity, team context, market value, agency, contract, availability, GBE, ratings, and shortlisting/squad flags. |
|
|
18
|
+
| Head coaches | `/coaches` | Coach identity, career history, tactical profile, ratings, contract, agency, and team-impact fields. |
|
|
19
|
+
| Teams | `/teams` | Team identity, competition context, head coach, squad value, team rating, and predicted requirements. |
|
|
20
|
+
| Transfers | `/transfers` | Player movement records with from/to teams, date, type, fee, and xTV at date/end. |
|
|
21
|
+
| Pitches | `/pitches` | Pitches and plus pitches received by a club on TransferRoom. |
|
|
22
|
+
| Requirements | `/requirements` | Club recruitment requirements, including position, age, height, foot, style, fee, and salary ranges. |
|
|
23
|
+
| Injuries | `/injuries/competitions`, `/injuries/players` | Injury histories, sources, return dates, recurrence/occurrence rates, workload, and risk/availability metrics. |
|
|
24
|
+
|
|
25
|
+
## Player model
|
|
26
|
+
|
|
27
|
+
The player object centres on recruitment decision support. Public sample fields include:
|
|
28
|
+
|
|
29
|
+
| Area | Fields |
|
|
30
|
+
|---|---|
|
|
31
|
+
| Identity | `TR_ID`, `Name`, `BirthDate`. |
|
|
32
|
+
| Club context | `ParentTeamId`, `CurrentTeamId`, `ParentTeam`, `CurrentTeam`, `TeamHistory`. |
|
|
33
|
+
| Competition context | `Country`, `CompetitionId`, `Competition`, `DivisionLevel`, `ParentCountry`, `ParentCompetition`, `ParentDivisionLevel`. |
|
|
34
|
+
| Nationality and role | `Nationality1`, `Nationality2`, `FirstPosition`, `SecondPosition`, `PlayingStyle`, `PreferredFoot`. |
|
|
35
|
+
| Contract and agency | `ContractExpiry`, `Agency`, `AgencyVerified`. |
|
|
36
|
+
| Workflow flags | `Shortlisted`, `AvailableSale`, `AvailableLoan`, asking-price and loan-fee fields. |
|
|
37
|
+
| GBE | `GBEScore`, `GBEResult`, and point-breakdown fields such as international appearances, domestic minutes, continental minutes, league position, continental progression, and league standard. |
|
|
38
|
+
| Value and rating | `xTV`, xTV change/history fields, `BaseValue`, `EstimatedSalary`, `Rating`, `Potential`. |
|
|
39
|
+
|
|
40
|
+
`TeamHistory`, `xTVHistory`, and `BaseValueHistory` are shown as JSON-encoded history strings in the public samples.
|
|
41
|
+
|
|
42
|
+
## Coach model
|
|
43
|
+
|
|
44
|
+
Head coach data includes:
|
|
45
|
+
|
|
46
|
+
- `TR_ID`, `Name`, `BirthDate`
|
|
47
|
+
- `Nationality1`, `Nationality2`
|
|
48
|
+
- `CurrentTeam`, `CurrentRole`
|
|
49
|
+
- `CareerHistory`
|
|
50
|
+
- `Country`, `Competition`, `DivisionLevel`
|
|
51
|
+
- `PreviousTeam`
|
|
52
|
+
- `ContractExpiry`
|
|
53
|
+
- `Agency`, `AgencyVerified`
|
|
54
|
+
- `Rating`, `RatingChange12m`
|
|
55
|
+
- `TacticalStyle`
|
|
56
|
+
- `Suitability`
|
|
57
|
+
- `TeamRatingImpact`
|
|
58
|
+
- `TrustInYouth`
|
|
59
|
+
- `PreferredFormation`
|
|
60
|
+
- `SquadRotation`
|
|
61
|
+
- `ThreeSeasonAvgSpend`
|
|
62
|
+
|
|
63
|
+
This makes TransferRoom useful for both player recruitment and head-coach succession/replacement workflows.
|
|
64
|
+
|
|
65
|
+
## Team model
|
|
66
|
+
|
|
67
|
+
Team data includes:
|
|
68
|
+
|
|
69
|
+
- `TR_ID`
|
|
70
|
+
- `Team`
|
|
71
|
+
- `Country`
|
|
72
|
+
- `CompetitionId`
|
|
73
|
+
- `Competition`
|
|
74
|
+
- `CompetitionDivisionLevel`
|
|
75
|
+
- `HeadCoachID`
|
|
76
|
+
- `TotalxTV`
|
|
77
|
+
- `TotalBaseValue`
|
|
78
|
+
- `AverageStarterRating`
|
|
79
|
+
- `TeamRating`
|
|
80
|
+
- `TeamRatingHistory`
|
|
81
|
+
- `PredictedRequirements`
|
|
82
|
+
|
|
83
|
+
`TeamRatingHistory` is shown as a JSON-encoded time series in the public sample.
|
|
84
|
+
|
|
85
|
+
## Transfer model
|
|
86
|
+
|
|
87
|
+
Transfer records include:
|
|
88
|
+
|
|
89
|
+
- `PlayerId`
|
|
90
|
+
- `Player`
|
|
91
|
+
- `FromTeamId`, `FromTeam`
|
|
92
|
+
- `ToTeamId`, `ToTeam`
|
|
93
|
+
- `Date`
|
|
94
|
+
- `TransferType`
|
|
95
|
+
- `TransferFee`
|
|
96
|
+
- `xTVatDate`
|
|
97
|
+
- `xTVatEnd`
|
|
98
|
+
|
|
99
|
+
This is a historical movement surface rather than a live rumour feed.
|
|
100
|
+
|
|
101
|
+
## Pitch and requirement model
|
|
102
|
+
|
|
103
|
+
`/pitches` describes inbound market activity to a club:
|
|
104
|
+
|
|
105
|
+
- Pitch subject: `Player`, `PlayerId`, `HeadCoach`, `HeadCoachId`
|
|
106
|
+
- Sender: `PitchedByTeam`, `PitchedByTeamID`, `PitchedByAgency`, `PitchedByAgencyID`
|
|
107
|
+
- Commercial terms: `PitchCurrency`, `PitchTransferFee`, `PitchGrossAnnualSalary`, `PitchLoanFee`, `PitchSellOnPerc`
|
|
108
|
+
- Workflow: `PitchType`, `RequirementID`, `PitchDate`, `PitchMessage`, `PitchStatus`
|
|
109
|
+
|
|
110
|
+
`/requirements` describes the club's posted recruitment need:
|
|
111
|
+
|
|
112
|
+
- `Active`, `UpdatedAt`
|
|
113
|
+
- `TransferType`
|
|
114
|
+
- `Position`, `Foot`, `PlayingStyle`, `PreferredNationality`
|
|
115
|
+
- `FromAge`, `ToAge`, `MinHeight`
|
|
116
|
+
- `TransferFee`, `GrossAnnualSalary`, `MonthlyLoanFee`
|
|
117
|
+
|
|
118
|
+
Together, pitches and requirements represent a club-specific workflow surface. They are not general public market data.
|
|
119
|
+
|
|
120
|
+
## Injury model
|
|
121
|
+
|
|
122
|
+
The injury products have two levels:
|
|
123
|
+
|
|
124
|
+
- Competition-level injury records: individual injury events with injury type, body part, start/return dates, sources, recurrence, surgery/training flags, and cohort recurrence/occurrence benchmarks.
|
|
125
|
+
- Player-level injury and availability records: recent minutes, minutes percentiles, match-missed percentage, injury risk rating, xAvailability, workload, and embedded player injury history.
|
|
126
|
+
|
|
127
|
+
The public docs say Advanced Injury Data covers 50 leagues, has historical data back to 2017, and includes recurrence risk, player injury risk rating, and fatigue/workload-style predictive metrics.
|
|
128
|
+
|
|
129
|
+
## Values and ratings
|
|
130
|
+
|
|
131
|
+
Important proprietary/derived metrics in the public docs:
|
|
132
|
+
|
|
133
|
+
| Field | Meaning |
|
|
134
|
+
|---|---|
|
|
135
|
+
| `xTV` | Expected Transfer Value. |
|
|
136
|
+
| `xTVChange6mPerc`, `xTVChange12mPerc` | Recent xTV percentage movement. |
|
|
137
|
+
| `xTVHistory` | xTV history time series. |
|
|
138
|
+
| `BaseValue`, `BaseValueHistory` | Base value and history. |
|
|
139
|
+
| `EstimatedSalary` | Salary estimate range. |
|
|
140
|
+
| `Rating`, `Potential` | Player/coach evaluation fields. |
|
|
141
|
+
| `TeamRating`, `AverageStarterRating` | Team-level rating fields. |
|
|
142
|
+
| `xAvailability` | Predicted future injury availability percentage. |
|
|
143
|
+
|
|
@@ -0,0 +1,132 @@
|
|
|
1
|
+
---
|
|
2
|
+
source_url: https://v0-simple-api-documentation-templat.vercel.app/
|
|
3
|
+
source_type: crawled
|
|
4
|
+
upstream_version: null
|
|
5
|
+
crawled_at: 2026-07-09
|
|
6
|
+
---
|
|
7
|
+
|
|
8
|
+
# TransferRoom Identity Surfaces
|
|
9
|
+
|
|
10
|
+
## Primary IDs
|
|
11
|
+
|
|
12
|
+
The public docs use `TR_ID` as the primary TransferRoom identifier on several entity types:
|
|
13
|
+
|
|
14
|
+
- Players: `TR_ID`
|
|
15
|
+
- Head coaches: `TR_ID`
|
|
16
|
+
- Teams: `TR_ID`
|
|
17
|
+
- Requirements: `TR_ID`
|
|
18
|
+
|
|
19
|
+
Some endpoint-specific fields use entity-specific names:
|
|
20
|
+
|
|
21
|
+
- `CompetitionId` or `Id` for competitions.
|
|
22
|
+
- `PlayerId` for player references in transfers, pitches, and injury records.
|
|
23
|
+
- `HeadCoachID` or `HeadCoachId` for coach references.
|
|
24
|
+
- `TeamId`, `FromTeamId`, `ToTeamId`, `PitchedByTeamID`, and similar fields for team references.
|
|
25
|
+
- `RequirementID` for linking a pitch to a posted recruitment requirement.
|
|
26
|
+
|
|
27
|
+
Store IDs with entity namespaces. For example, do not assume that player `TR_ID=123` and team `TR_ID=123` refer to the same object.
|
|
28
|
+
|
|
29
|
+
## Player identity fields
|
|
30
|
+
|
|
31
|
+
The player surface includes:
|
|
32
|
+
|
|
33
|
+
- `TR_ID`
|
|
34
|
+
- `Name`
|
|
35
|
+
- `BirthDate`
|
|
36
|
+
- `Nationality1`
|
|
37
|
+
- `Nationality2`
|
|
38
|
+
- `ParentTeamId`, `ParentTeam`
|
|
39
|
+
- `CurrentTeamId`, `CurrentTeam`
|
|
40
|
+
- `TeamHistory`
|
|
41
|
+
- `CompetitionId`, `Competition`
|
|
42
|
+
- `FirstPosition`, `SecondPosition`
|
|
43
|
+
- `PreferredFoot`
|
|
44
|
+
|
|
45
|
+
For matching players to another provider, use `TR_ID` as the TransferRoom key and combine name, birth date, nationality, current/parent teams, positions, and team history as disambiguation evidence.
|
|
46
|
+
|
|
47
|
+
## Coach identity fields
|
|
48
|
+
|
|
49
|
+
The coach surface includes:
|
|
50
|
+
|
|
51
|
+
- `TR_ID`
|
|
52
|
+
- `Name`
|
|
53
|
+
- `BirthDate`
|
|
54
|
+
- `Nationality1`
|
|
55
|
+
- `Nationality2`
|
|
56
|
+
- `CurrentTeam`
|
|
57
|
+
- `CurrentRole`
|
|
58
|
+
- `CareerHistory`
|
|
59
|
+
- `PreviousTeam`
|
|
60
|
+
- `ContractExpiry`
|
|
61
|
+
- `Agency`
|
|
62
|
+
|
|
63
|
+
Coach identity should be treated separately from player identity even if the person is historically both a former player and a coach.
|
|
64
|
+
|
|
65
|
+
## Team and competition identity fields
|
|
66
|
+
|
|
67
|
+
Team fields include:
|
|
68
|
+
|
|
69
|
+
- `TR_ID`
|
|
70
|
+
- `Team`
|
|
71
|
+
- `Country`
|
|
72
|
+
- `CompetitionId`
|
|
73
|
+
- `Competition`
|
|
74
|
+
- `CompetitionDivisionLevel`
|
|
75
|
+
- `HeadCoachID`
|
|
76
|
+
|
|
77
|
+
Competition fields include:
|
|
78
|
+
|
|
79
|
+
- `Id`
|
|
80
|
+
- `CompetitionName`
|
|
81
|
+
- `Country`
|
|
82
|
+
- `DivisionLevel`
|
|
83
|
+
- `Teams`
|
|
84
|
+
|
|
85
|
+
For local mirrors, store a stable competition table before consuming team, transfer, and injury feeds. Several endpoints use `competitionid` as a query parameter.
|
|
86
|
+
|
|
87
|
+
## Transfer linkage fields
|
|
88
|
+
|
|
89
|
+
The transfer surface links players and clubs through:
|
|
90
|
+
|
|
91
|
+
- `PlayerId`
|
|
92
|
+
- `Player`
|
|
93
|
+
- `FromTeamId`, `FromTeam`
|
|
94
|
+
- `ToTeamId`, `ToTeam`
|
|
95
|
+
- `Date`
|
|
96
|
+
- `TransferType`
|
|
97
|
+
|
|
98
|
+
Use `PlayerId`, `FromTeamId`, and `ToTeamId` for identity joins. Team and player names should be treated as display or fallback matching fields.
|
|
99
|
+
|
|
100
|
+
## Pitch and requirement linkage
|
|
101
|
+
|
|
102
|
+
Pitches can link back to requirements and to the pitched subject:
|
|
103
|
+
|
|
104
|
+
- `RequirementID`
|
|
105
|
+
- `PlayerId`
|
|
106
|
+
- `HeadCoachId`
|
|
107
|
+
- `PitchedByTeamID`
|
|
108
|
+
- `PitchedByAgencyID`
|
|
109
|
+
|
|
110
|
+
If `RequirementID` is null, the pitch was not tied to a posted requirement in the public sample. A pitch may concern either a player or a head coach, so code should tolerate one subject being null.
|
|
111
|
+
|
|
112
|
+
## Injury identity fields
|
|
113
|
+
|
|
114
|
+
Competition injury records use:
|
|
115
|
+
|
|
116
|
+
- `TR_ID` for the player
|
|
117
|
+
- `Name`
|
|
118
|
+
- `TeamId`, `Team`
|
|
119
|
+
- `CompetitionId`, `Competition`
|
|
120
|
+
|
|
121
|
+
Player injury records use:
|
|
122
|
+
|
|
123
|
+
- `TR_ID`
|
|
124
|
+
- `Name`
|
|
125
|
+
- `BirthDate`
|
|
126
|
+
- `PlayerInjuries`
|
|
127
|
+
|
|
128
|
+
For injury joins, prefer `TR_ID`/`PlayerId` over names. Injury records include current team context at the time of injury, which can differ from current club context in `/players`.
|
|
129
|
+
|
|
130
|
+
## Cross-provider caveat
|
|
131
|
+
|
|
132
|
+
The public docs do not show explicit third-party IDs such as Wyscout, StatsBomb, Transfermarkt, or Football Manager IDs. Treat TransferRoom identity as its own namespace and build cross-provider matches from names, birth dates, team history, nationality, competition context, and dates unless TransferRoom provides additional private mapping fields under contract.
|
package/package.json
CHANGED
package/providers.json
CHANGED
|
@@ -61,6 +61,17 @@
|
|
|
61
61
|
],
|
|
62
62
|
"last_crawled": null
|
|
63
63
|
},
|
|
64
|
+
"transferroom": {
|
|
65
|
+
"description": "Commercial football transfer-market and recruitment API for player, coach, team, transfer, pitch, requirement, and injury data",
|
|
66
|
+
"version": null,
|
|
67
|
+
"package": null,
|
|
68
|
+
"sources": [
|
|
69
|
+
{ "url": "https://www.transferroom.com/api-docs", "type": "api_docs", "note": "Public API documentation page; embeds the current docs application" },
|
|
70
|
+
{ "url": "https://v0-simple-api-documentation-templat.vercel.app/", "type": "api_docs", "note": "Embedded API documentation application with endpoint examples and field descriptions" },
|
|
71
|
+
{ "type": "curated", "note": "Endpoint grouping, access-tier, data model, and identity-resolution guidance from the public docs" }
|
|
72
|
+
],
|
|
73
|
+
"last_crawled": "2026-07-09"
|
|
74
|
+
},
|
|
64
75
|
"soccerdonna": {
|
|
65
76
|
"description": "Public women's football entity pages, match reports, competition pages, player profiles, and staff profiles",
|
|
66
77
|
"version": null,
|
|
@@ -79,6 +90,17 @@
|
|
|
79
90
|
],
|
|
80
91
|
"last_crawled": null
|
|
81
92
|
},
|
|
93
|
+
"fmdb-pro": {
|
|
94
|
+
"description": "Sports Interactive commercial football database API for clubs, players, people, competitions, geography, values, appearances, and GBE-related fields",
|
|
95
|
+
"version": "latest",
|
|
96
|
+
"package": null,
|
|
97
|
+
"sources": [
|
|
98
|
+
{ "url": "https://app.fmdb.pro/docs", "type": "api_docs", "note": "Redoc/Swagger documentation UI" },
|
|
99
|
+
{ "url": "https://api.fmdb.pro/api/openapi", "type": "api_docs", "note": "OpenAPI 3.0.2 spec; local snapshot at specs/fmdb-pro/openapi.json" },
|
|
100
|
+
{ "type": "curated", "note": "Endpoint grouping, data model, and identity-resolution guidance from the OpenAPI spec" }
|
|
101
|
+
],
|
|
102
|
+
"last_crawled": "2026-07-09"
|
|
103
|
+
},
|
|
82
104
|
"impect": {
|
|
83
105
|
"description": "Commercial football data provider; Packing/pxT metrics, KPI/score framework, detailed set-pieces (Customer API v5)",
|
|
84
106
|
"version": "Customer API v5.0",
|