Widgets

Widget script

GEThttps://sportsapi.app/widgets/v1.jsAll plans
View as Markdown

The widget script. Put one element per widget where it should appear, then the script once with your widget key. Types: livescore (data-sport required, data-league optional — the live matches of a sport, grouped by league), match (data-fixture — score, status, goals, cards and substitutions), standings (data-league, data-season optional — the season’s main table, newest season by default). Options: data-size small | medium | large (where it goes: a sidebar — at most 340 px, compact, standings with P and Pts only; a content column — at most 640 px, the default; full width with larger type), data-theme light | dark | auto (the visitor’s setting), data-accent (#hex), data-refresh (seconds, at least 15; defaults 30 / 30 / 600). The dashboard’s Widgets tab previews every choice with sample data.

A widget key (pk_live_…) is public by design: it works only from the sites it lists (the browser’s Origin — exact, or https://*.example.com for subdomains), only for the endpoints the widgets read (livescores, fixtures and their events / lineups / statistics, league seasons and standings), and only while your plan has widgets. Elsewhere it answers 403 origin_not_allowed or endpoint_not_in_plan. Every refresh is a request against your quota — a livescore widget open in 100 browsers for an hour is 12,000 requests at the default 30 s. Widgets render in their own shadow root, so your CSS does not reach them.

Every /v2 call can also answer the common errors.

Example
<div data-sportsapi-widget="livescore" data-sport="football" data-league="17"></div>
<div data-sportsapi-widget="standings" data-league="17" data-theme="dark"></div>
<script src="https://sportsapi.app/widgets/v1.js" data-key="pk_live_…" async></script>