Replace a DraftKings scraper with an API

What a scraper costs to keep

A scraper is cheap to write and expensive to keep running. The work is rarely the first parser. It is everything that happens after the source changes or starts refusing requests.

• Parsers break when page structure or response fields change, often without an obvious error.
• Sources answer heavy automated traffic with 403 and 429 responses, and proxies add cost and failure modes of their own.
• Without stored captures, a missed run is a permanent gap in your history.
• Silent partial captures look like valid data unless you record what you asked for and what came back.
• Source terms can restrict automated access. That is your question to answer with your own counsel, whichever method you use.

What this API replaces

This API replaces the collection and storage layer for the datasets it covers. You read stored rows over HTTP with a key, and collection, rotation and cooldowns happen on our side.

What it does not replace

Be clear about gaps before you switch off anything. As of 2026-11-03, native sportsbook scopes cover New York NFL, NHL, college basketball and college football game lines and New York NHL Shots on Goal, points, assists, saves, goalscorers, power-play points and first-period shots. Read snapshots and streamed changes through the sportsbook endpoints. ESPN-attributed DraftKings moneyline, spread and total observations are also available across eight leagues. Current scope inventory is listed at /api/v1/sportsbook/scopes. If your scraper reads sportsbook props or alternates outside the listed native scopes, this API does not replace that part.

• Coverage is selected. If your scraper fetches a Pick6 category or DFS slate that is not captured, you will not find it here. Measure this first.
• Worker targets are five minutes for sportsbook and Pick6 and fifteen for DFS, with no freshness guarantee. A scraper tuned to run faster than that would lose speed.
• History started around the date in historical data. Your own archive may go back further, so keep it.
• An API key does not clear rights. Technical access is not a redistribution license, and moving to this API does not settle whether your product may republish the data.

Use an adapter, not a rewrite

Keep your models, storage and downstream code. Add one small function that maps API rows to the shape your code already reads, and keep the raw row beside it. Then you can run both sources in parallel and switch with one flag.

def from_api(row):
    """Map one Pick6 API row to the shape the existing pipeline reads."""
    entity = row["entities"][0] if row.get("entities") else {}
    return {
        "market_key": (row["pick_group_id"], row["pickable_id"], row["pickable_market_id"]),
        "player": entity.get("full_name"),
        "dk_player_id": entity.get("entity_id"),
        "stat": row["stat"],
        "target": row["target_value"],
        "selections": row["selections"],   # keep every side as observed
        "paused": row["is_paused"],
        "captured_at": row["observed_at"], # capture clock, not a venue clock
        "stale": row["stale"],
        "raw": row,
    }

Do not rename observed_at to something like updated_at. source_updated_at is null because the venue clock is unknown, and a later reader should still be able to see that. Details are in freshness.

Run both before you switch

Run the API read and your scraper side by side for several game days. Compare what each one sees and write down the differences before deciding.

1. Pick the sports and stats your product depends on and call /api/v1/coverage.
2. Each run, fetch the same scope through both paths and store the results with their capture times.
3. Compare by source identity, not by player name: pick_group_id, pickable_id and pickable_market_id for Pick6, draftableId for DFS.
4. Count rows only one path saw, target values that differ and how old each path's rows are.
5. Budget requests. Page sizes are capped at 100, and one call is one request, so work out monthly usage on pricing.
6. Switch one consumer at a time, and keep the scraper's archive.

Your scraper's captures may disagree with API rows without either being wrong, because the two capture at different times. Compare observed_at before calling something an error.

Replace the polling loop too

A scraper habit worth dropping is polling as fast as possible. Faster polling here returns the same stored rows and spends quota. Poll no faster than the collector interval, cache responses on your side and continue change history from a saved cursor.

curl --fail-with-body "https://draftkingsapi.com/api/v1/pick6/history?sport=NFL&after=0&limit=25" \
  -H "Authorization: Bearer $DRAFTKINGS_API_KEY"

Continue with pagination.next_after as after and offset=0, and save the cursor only after processing a page. See line movement. The full migration checklist is on scraper to API migration.

Check the recorded data

• Sources and status
• Measured coverage report

Related resources