Historical data

A live key sees the full archive — every race, runner and result on record, with no rolling window. (Free sandbox keys see yesterday, today and ahead only.) There are two ways to work with it: pull the archive in bulk, or look one dog up at a time.

Full means every race we hold, which is not every race that runs — see What we cover for the regions, and the racing calendar for which tracks appear on which days.

Most detail already lives in the result

You rarely need to stitch endpoints together. Each finisher in a result already carries its timing, price and running detail, so a single pass over /results gives you almost everything at once:

Greyhound racing records a single sectional — the split to the first bend — not a series of per-section splits as in horse racing. So sectional_s is the split figure; there is nothing more granular, which is the nature of the sport rather than a gap in the data.

Bulk import — walk the results archive

The efficient way to build an analysis set or a training corpus is to page /results across a date range and follow the cursor. Narrow it with region, track, dog_id, trainer_id or owner_id as needed.

curl "https://api.greyhoundapi.com/v1/results?date_from=2024-01-01&date_to=2024-12-31&limit=200" \
  -H "X-API-Key: $GAPI_KEY"

# then follow meta.next_cursor until it is absent:
curl "https://api.greyhoundapi.com/v1/results?date_from=2024-01-01&date_to=2024-12-31&limit=200&cursor=..." \
  -H "X-API-Key: $GAPI_KEY"

Use limit=200 and the cursor — not page numbers — for a full pull; see Pagination. Keep an eye on your rate limits and back off on a 429. For the racecard side of the archive (entries rather than results), /races pages the same way.

One dog at a time

When you want a single animal's history rather than the whole archive, these return it directly, with no client-side joining:

The same career form is also reachable by filtering /results with dog_id, so for a large model you can usually stay on the bulk endpoint and skip the per-dog calls entirely.