How to test a football data API in 14 days

Decide what works before day 1

Start with one user journey. For a livescore app, that might be opening a competition, selecting a match and seeing its score, events and team statistics. List the exact leagues and fields required for that journey before adding features for a later release.

Give each requirement a measurable acceptance rule. ‘Fast enough’ is difficult to test. ‘A score update reaches our match screen within our chosen delay under the expected polling load’ gives you something to measure. Set that delay from your product needs; a trial does not create a provider guarantee.

Separate requirements that block launch from preferences. If confirmed lineups are essential, missing lineup evidence cannot be offset by attractive team logos or a useful historical archive. Record a result as pass, fail or not tested, with the saved response or screen that supports it.

Our guide to choosing a football data provider helps you choose evaluation criteria. This plan turns those criteria into scheduled work. Keep the same criteria if you evaluate another provider so differences in your test do not decide the result for you.

Confirm access before starting the clock

Our plans and pricing page shows the current options. The ongoing free plan and a trial of a paid plan are separate options. Before you plan around a trial, confirm its duration, included features, add-ons, billing method and cancellation terms for the account you will use. Check the end date in your account, then schedule your live sessions and final decision within that window.

Ask about any feature your launch depends on, such as live xG or a particular odds feed. A plan name alone does not establish competition-level availability or whether a specialist feature is enabled for your trial. Record the trial end date and the billing or cancellation conditions shown when you activate it.

Book time for two live match sessions and the final decision now. Starting a trial immediately before leave, or during a quiet fixture window, gives your team fewer opportunities to test the parts that matter most.

The 14-day plan

Each day should leave evidence another developer can review: a response, a working screen, an error-handling result or a short decision note. Schedule live sessions around your leagues’ actual fixtures and keep the other checks in place.

Days 1 to 3: get data into your application

Use our first-request guide to create a token and make a server-side request. Get one known fixture from a league included in your API plan, then add only the relations your first screen needs. Keep the token out of browser code, screenshots and shared logs.

Use a known completed fixture from a league in your plan. Replace the token placeholder before you run the request. This example returns the teams and score for Manchester City versus Manchester United:

GET https://api.sportmonks.com/v3/football/fixtures/18842545?api_token={{API_TOKEN}}&include=participants;scores

Trimmed response from this fixture:

{
  "data": {
    "id": 18842545,
    "name": "Manchester City vs Manchester United",
    "starting_at": "2024-03-03 15:30:00",
    "participants": [
      {"id": 9, "name": "Manchester City", "meta": {"location": "home"}},
      {"id": 14, "name": "Manchester United", "meta": {"location": "away"}}
    ],
    "scores": [
      {"participant_id": 9, "score": {"goals": 3, "participant": "home"}, "description": "CURRENT"},
      {"participant_id": 14, "score": {"goals": 1, "participant": "away"}, "description": "CURRENT"}
    ]
  }
}

The fixture-by-ID reference documents the available includes. Save a redacted response and map fixture and participant IDs into your application. Make sure the UI identifies home and away teams from the returned relationships rather than assuming the participants array always arrives in display order.

Test a completed match, a future match and a match with limited data. A parser that works for a full historical response can still fail when an upcoming fixture has no score. By day three, your smallest match screen should work with those different states.

Days 4 to 7: observe live behaviour

Use our livescore endpoints for live collection. Log when your server receives each response and when your frontend displays the change. Measure request duration separately from the delay between a football event and its appearance on screen.

If you compare against a broadcast, record the source and remember that the broadcast itself can be delayed. That comparison measures a relationship between two feeds; it does not establish the exact instant the event happened at the stadium.

Watch a full collection cycle, including kick-off, half-time and full time where available. Check whether your frontend clears stale loading states, distinguishes no current matches from a failed request, and keeps displaying the last successful observation during a temporary failure.

Arrange a second live session rather than relying on one match. Include simultaneous fixtures if your launch needs them. Save exceptions and unanswered questions while they are fresh, then use day seven to review what remains untested.

Days 8 to 11: exercise the difficult paths

Check missing fields, request failures and changed observations. Use controlled test responses to exercise a rescinded event or an amended value if no real change appears during the trial. Label these as local tests; they demonstrate your application’s behaviour, not a measured correction by the provider.

Test repeated delivery too. Applying the same response twice should not duplicate a goal, a notification or a stored statistic. A timeout should not replace a valid match record with an empty object, and a missing included relation should not silently erase existing data.

Build your busiest-hour request estimate before increasing traffic. On our API, limits are shared by entity, so live collection and other fixture requests need to fit together. Use the returned allowance information and our rate-limit guidance, rather than assuming each endpoint has a separate budget.

For example, one request every ten seconds means 360 requests an hour. Twenty independent fixture jobs at that interval mean 7,200 requests before retries, pagination or other activity. A shared collection job can reduce duplication, but verify the response contains everything your screen needs before changing the design.

Days 12 to 14: close the gaps and decide

Use day twelve to retest fixes with the same acceptance rules. Run a complete workflow rehearsal from collection through storage to the match screen. Check that cache invalidation and background jobs behave correctly after a restart, rather than testing the HTTP request in isolation.

On day thirteen, review the expected ongoing API plan, add-ons and operational work. Ask whoever owns the product to check the permitted storage, display and redistribution under our terms of service. Include rights questions about imagery if your design uses badges or player photos.

On day fourteen, make a written decision. Proceed when every launch blocker has evidence and the remaining work is understood. Narrow the launch if a smaller, tested set of leagues or features is sufficient. If essential live evidence is still missing, record that gap and discuss the next step rather than treating an incomplete trial as a pass.

Checking coverage depth and corrections

Start with our coverage page, then check actual fixture responses for your launch leagues. League coverage, access under your API plan and the presence of a specific field are separate checks. Our data-features guidance explains how to investigate specialist availability.

For a livescore screen, inspect team statistics, match events and player statistics individually. A response containing teams and a score does not establish player-level coverage. Check both starting lineups and substitutes when the feature needs them, and verify when the required data becomes available.

Preserve the difference between a numeric zero, a null value and an absent record. Zero shots is a valid observation. An unavailable statistic should produce an appropriate empty state rather than a misleading zero. Keep the original response alongside your normalized output while investigating discrepancies.

Fetch selected completed fixtures again during the trial and compare their stored values with the new responses, using the same request and includes. Match records by ID and compare the fields that matter, not the order of items in the response. If something changes, check whether the cause is a factual amendment, a difference in access or a change to the request.

Do not promise that a short trial will contain a real correction. If none occurs, retain the local correction test and ask support how to handle amendments for the fields your product uses. A synthetic test demonstrates resilience in your code; it cannot establish a provider’s correction frequency or turnaround time.

Check the effect beyond the match page. If an event attribution changes, your player totals, cached summaries or generated alerts may also need attention. Test that applying an update changes the relevant derived views without creating duplicate records.

Scorecard for the decision

Use this scorecard with your own acceptance rules. Mark each result as pass, fail or not tested, and attach evidence to every pass. Any critical requirement without a pass remains a launch blocker.

Mark the requirements that block your launch before you start testing. A live-score app may depend on an observed live feed; a historical analysis tool may have different blockers.

Ready to make your first request? Start with our free plan and use this schedule to collect evidence for your application.