Build a football match centre

Divide the page into panels: a header with teams, crests, kick-off time and status; a team news panel with expected or confirmed line-ups; an events timeline; a statistics comparison; context from the standings and head-to-head history; and links to both team pages. Each panel reads from stored data and renders independently.

Independent panels mean one missing piece does not break the page. If statistics are not yet available, the rest still renders.

Give each panel a small last-refreshed label, since panels may refresh on different schedules.

The header shows both teams with crests from our media route, the competition name in text, the kick-off time converted to the reader's zone with a zone label, and the status. Before kick-off, show a countdown computed in the browser. After kick-off, show the status and score from the latest refresh, with its time.

Never show a pulsing live indicator. A neutral label such as last updated with the time is accurate and sufficient.

Before the match, show predicted line-ups where the competition supports them, clearly labelled as expected. When confirmed line-ups arrive in the match detail feed, replace the expected ones and say so. Link every player to their profile by identifier.

If neither expected nor confirmed line-ups are available, say that team news is not yet available rather than leaving an empty grid.

Render events in supplied order with minute and added time: goals, cards, substitutions. Use icons with accessible labels and player names as text. After the match, the timeline tells the story; a short editorial summary can sit above it if you have writers.

Corrections happen, such as a goal reassigned to a different scorer. Refresh the match detail the morning after and update the timeline.

Show team statistics side by side with clear labels and numbers as text, plus optional bars. Hide rows where one team's value is missing. Avoid derived metrics you cannot explain.

Include each team's current position from the standings feed and a compact head-to-head summary for the pairing. Present history as dated context, not a forecast. FootballAPI.net publishes no tips or odds, and the match centre should not imply any.

Before match day, refresh fixtures and expected line-ups at a pace appropriate to their update cycle. During play, use one shared worker for current scores and supported match detail, not one request per visitor. Refresh again after full time for corrections. Starter includes 5,000 successful requests per day, Growth 25,000 and Pro 250,000; the account safety limit is 100 requests per second. That ceiling is not a recommended polling rate or a guarantee of fresh data on every call.

All refreshes run on the server and write to storage. The page reads only from storage.

Every panel needs an empty state and an error state. Write them deliberately: team news not yet announced, statistics available after the match, timeline will appear once events are recorded. Errors should offer a retry and keep showing any older data with its time.

These states are visible on most match pages most of the time, so they deserve the same care as the populated ones.

The match identifier is the spine. Fixtures, match detail and predicted line-ups all join on it. Teams join on team identifiers, players on player identifiers. Keep those joins in your data layer, and the page template becomes simple.

For a Saturday match in league 1204, the page exists from the moment fixtures are stored. On Friday it shows the header with a countdown, an expected line-ups panel and context from the table and head-to-head history. An hour before kick-off, a refresh brings confirmed line-ups and the panel switches labels. After full time, refreshes populate the timeline and statistics, and the header shows the final score with its refresh time.

On Sunday morning, a final refresh catches a reassigned goal and updates the timeline. From then on, the page is effectively an archive report and needs no further requests.

Across a season of three hundred and eighty matches, this pattern gives a predictable number of requests per match. Budget for the busiest day rather than relying only on a season-wide average: published allowances are daily, and a quiet week does not imply that unused requests can be carried into a busy match day.

Most match centre traffic is on phones. Stack panels in order of reader interest: header, team news before the match, timeline after it, then statistics and context. Use tabs sparingly; scrolling is usually faster than tapping. Keep the header compact and sticky so the score and status stay visible while readers scroll through the timeline.

Test the page on a slow connection. Text should appear immediately from server-rendered HTML, with crests and player photos filling in afterwards without shifting the layout.

Give each match page a stable URL with a readable slug and the match identifier, a title naming both teams, the competition and date, and a description written from real fields. Social cards should show the teams and the status at the time of sharing, never a live claim.