← All field notes stable football API IDs

Stable Football IDs That Survive a Data Provider Replacement

Public identifiers should belong to your API contract, not to the data company that happens to feed it today.

Own the identifier namespace your customers integrate

If a public team ID is copied directly from an upstream vendor, replacing that vendor becomes a breaking API change. Customers have stored the value in databases, URLs, caches, and agent memory. Translating every integration at once is unrealistic. A provider-neutral API should issue its own stable IDs and keep upstream identifiers behind an ingestion boundary.

Each source adapter writes a crosswalk from its source entity to the canonical record. Public responses include only the canonical Stats API ID. This also lets multiple sources contribute evidence to one record without creating a second public identity. The crosswalk carries source, source ID, confidence, timestamps, and review state.

Treat provider replacement as a data migration

Load the new source in parallel, build candidate mappings, and compare coverage and key fields before changing production reads. Exact name matching is insufficient. Country, competition, season, known aliases, participants, and schedule context may all help, but uncertain matches need human review. It is safer to leave a record unmapped than to merge two clubs incorrectly.

Run shadow ingestion and diff normalized output. Measure missing records, changed timestamps, score disagreements, and freshness. Keep the old adapter and crosswalk available for rollback until the new path has passed defined acceptance targets. Because public IDs remain unchanged, customers and agents do not need a mass rewrite when the internal source changes.

  • Canonical public ID: stable customer contract.
  • Provider crosswalk: internal, versioned, reviewable.
  • Shadow run: compare normalized records before cutover.
  • Rollback: restore the prior source without changing public IDs.

A handoff your agent can actually follow

Treat an AI agent as a planner and transformer, not as the database. Give it a narrow task, the exact resources it may call, the response fields it may quote, and a stop condition for missing data. Keep bearer credentials in the server-side tool implementation rather than in the prompt, transcript, browser, or generated source file.

The handoff below is deliberately operational. It asks for evidence before prose, makes uncertainty visible, and keeps the model inside the current football API contract. Adapt the output format to your product, but preserve the rules about stable IDs, UTC timestamps, freshness, and error handling.

Agent instruction text
Treat public Stats API IDs as immutable application identity.
Store provider identifiers only in internal crosswalk records.
Never expose a new provider ID as a replacement public ID.
Escalate uncertain entity matches for review and preserve a rollback map.

What the human reviewer still owns

Automation can verify schemas and repeatable checks, but publication and product decisions still need a person. Review the selected competition, season, team, and match IDs; confirm that the time window matches the user’s question; and read the final answer against the retrieved JSON. A fluent explanation is not evidence that the underlying call was correct.

For time-sensitive football AI, record when the source was ingested and when the agent retrieved it. If the workflow cannot establish those timestamps, qualify the result instead of presenting it as current. The same rule applies to unavailable capabilities: do not quietly substitute fixtures or results for lineups, player statistics, odds, expected goals, injuries, or live events.

  • Confirm every quoted fact appears in the retained API response.
  • Exercise the empty, 401, 404, 429, and 503 paths before launch.
  • Keep model interpretation separate from source facts in logs and user-facing output.
  • Sample crosswalks manually across renamed clubs, competitions, seasons, and rescheduled matches before any provider cutover.

Continue with the contract, not a guess

Start with the public contract and coverage ledger, then move into implementation only when the capability you need is marked available. The related guide gives your next agent-first pattern without requiring an undocumented endpoint.

Read the football API documentation → Review the football API product contract → Read the related agent-first guide →