Cricket Analytics Made Simple with SportDevs API

If you’ve ever tried to explain why a chase suddenly swung, you know cricket’s story lives between the numbers—pressure building through dots, a bowling change that chokes the run rate, a partnership that stabilizes the innings, or a death-overs burst that flips the equation. With clean endpoints for ball events and innings summaries, you can turn those moments into analytics fans immediately understand: run rate (RR), required run rate (RRR), strike rate (SR), economy, partnerships, and phase splits. This guide shows how to do that with the SportDevs Cricket API, using matches-innings for structured innings aggregates and matches-incidents for ball-by-ball style events—plus practical tips for realtime delivery, personalization, and rock-solid accuracy.

Note: Endpoint paths and field names below are example-oriented. Always confirm final schema and parameters in your SportDevs documentation.

What You Can Build

Smart scorecards: live totals, RR/RRR side-by-side, and “worm” graphs updating every event.
Phase dashboards: powerplay/middle/death splits for both innings (and format-aware variants).
Batter & bowler profiles: SR, boundary %, dot %, and economy—contextualized by match and season.
Partnership visualizations: stand totals with balls, 4s/6s, and fall-of-wicket marks.
Alerts: milestones (50/100), hat-trick balls, “RRR < 6” triggers for chases.

Key Endpoints at a Glance

Matches Incidents — ball-level incidents for a given match_id.
GET https://cricket.sportdevs.com/matches-incidents?match_id=eq.{id}

Returns an incidents array with fields such as over, ball, runs, wicket flags, batter/bowler IDs and names, and optional spatial tags.
Supports pagination via offset, limit and multi-language via lang (where available).

Matches Innings — structured innings aggregates for a given match_id.
GET https://cricket.sportdevs.com/matches-innings?match_id=eq.{id}

Returns an innings array with totals (score, wickets, overs, extras breakdown) plus partnerships and batting_lines (FOW, wicket types, player IDs/names).

Matches By Date — retrieve matches for a given date.
GET https://cricket.sportdevs.com/matches-by-date?date=eq.{YYYY-MM-DD}

Use for listings and prefetching match IDs for upcoming fixtures.

Matches Live — convenience endpoint for currently live games (same response shape as /matches).
GET https://cricket.sportdevs.com/matches-live

Tip: Consistent pagination and optional language parameters make these endpoints predictable for UIs and caches.

Quick Start: Fetch and Normalize

Example: incidents for one match

curl "https://cricket.sportdevs.com/matches-incidents?match_id=eq.12345&limit=50&offset=0&lang=en"

You’ll receive a shape like:

{
  "match_id": 12345,
  "incidents": [
    {
      "over": 3,
      "ball": 1,
      "runs": 0,
      "type": "ball",
      "class": "W",
      "wicket": true,
      "batsman_id": 90099,
      "bowler_id": 72527,
      "inning_number": 1
    }
  ]
}

From here:

Total runs this delivery = runs (and/or total_runs where present).
Legal ball counting: rely on the event class and match context; align totals to Innings aggregates to avoid drift.
Sequence: sort by over then ball; if the feed ever arrives slightly out of order, buffer and re-sort by these keys (or a provided sequence if present).

Example: innings aggregates

curl "https://cricket.sportdevs.com/matches-innings?match_id=eq.12345&lang=en"

Use innings[*].score, wickets, overs, extras (bye, leg_bye, wide, no_ball, penalty), plus partnerships and batting_lines to fast-track UI components like stands charts and FOW markers.

Core Metrics: Formulas That Power Your UI

Keep balls as integers internally; only format overs for display (14.3 = 14 overs + 3 balls = 87 balls).

Run Rate (RR): RR = (runs / legal_balls) * 6
Required Run Rate (RRR) (chasing): RRR = (target_remaining / legal_balls_remaining) * 6
Strike Rate (SR) (batter): SR = (runs / legal_balls_faced) * 100
Economy (bowler): Econ = (runs_conceded / legal_balls_bowled) * 6
Boundary %: (fours + sixes) / legal_balls_faced
Dot %: dots / legal_balls_faced

Align these with Innings totals; if a single-ball event is ambiguous, trust matches-innings as the authoritative aggregate for score parity.

Phase Analytics: Powerplay → Middle → Death

Map deliveries to phases by format (configurable):

T20: PP (1–6), Middle (7–15), Death (16–20)
ODI: PP1 (1–10), PP2 (11–40), PP3 (41–50)

For each phase compute runs, balls, and RR as above. Present both innings side-by-side to show intent shifts (e.g., conservative PP with an aggressive death push).

Partnerships: Telling the Real Batting Story

matches-innings already returns partnerships with balls, score, and player IDs/names—use it to render stands without reconstructing from raw events. Combine stands with FOW markers from batting_lines (e.g., fow_over, fow_score) to show where a partnership broke. This single view explains more than any single strike-rate number.

Display pattern ideas:

A stacked bar across the innings timeline, with hover tooltips (runs/balls/4s/6s).
Small wicket pins at fow_over along your worm chart.
A compact table listing the top three stands with player avatars from image/hash fields.

Realtime & Resilience

Cadence: Poll Incidents and Innings on a sensible interval during live (e.g., ~10s).
Ordering: keep a tiny buffer and sort by (over, ball) before rendering to avoid flicker.
Fallbacks: when sockets aren’t an option, poll on the cadence above; cache stable metadata (squads, venue) longer.
Pagination: respect limit/offset and roll a simple “load more” for deep histories.

Design Tips: Clear, Comparable, Explainable

RR & RRR together in chases; color when RRR drops below your “comfortable chase” threshold.
Phase labels over the worm: PP/Middle/Death chips with run-rate deltas.
Tooltips define legal delivery, extras, and economy once; reuse.
Context badges: compare batter SR to match SR and season SR for instant meaning.
Mobile first: always pin score, equation, and next milestone (e.g., “50 up in 3”).

KPIs, QA, and Edge Cases

KPIs

Latency: time from incident arrival → UI update.
Parity: RR/SR/Econ parity vs Innings totals.
Engagement: dwell time on live centre, tooltip opens, share rate.
Stability: reconnect rate, duplicate suppression.

Edge cases

Super overs: treat as additional innings; annotate clearly in UI.
Retired hurt / concussion sub: batting order changes mid-innings—confirm via batting_lines.
Penalty runs: add to runs, don’t increment legal balls; keep equations correct.
Interrupted matches (DLS): recalc targets; badge the method used so users understand swings.

FAQ

Do I need ball-by-ball to start?
No. matches-innings gives totals, extras, partnerships, and batting lines—the fastest route to parity-accurate scorecards. Use matches-incidents to add live narrative and worms.

How often should I call the endpoints during live?
A modest cadence such as one call every ~10 seconds is common. Respect limit/offset and avoid hammering the same window.

What date format should I use for Matches By Date?
Use ISO dates like YYYY-MM-DD when calling matches-by-date. Use this to pre-resolve match IDs for upcoming fixtures.

Can I localize responses?
Yes—add lang where supported. Pagination uses offset/limit across these endpoints.

Get Started

Browse the Cricket docs and test the examples: matches-innings, matches-incidents, matches-by-date, matches-live.
Stand up your live centre with a sensible cadence and a small event buffer.
Add phase splits and partnerships to turn numbers into stories fans understand.