Race photo finder: face search for marathons and races
Runners upload one selfie and get every course photo they appear in, including the ones where the bib is covered.
Race photography is a volume problem. A city marathon produces tens of thousands of photos from photographers spread along the course, and the usual way of sorting them, reading the bib number, fails whenever a jacket, an arm or a gel belt covers it. Face search finds the runner instead of the number. SightRadar does not read bibs. If you already tag by bib, face search fills in the photos the bib reader missed.
Who builds this: Race photo companies, timing providers and race organisers who sell or give away course photos.
the workflow
How it goes together
- 1
Create a collection per race edition
POST /v1/collectionsOne collection per race and year, for example `city-marathon-2026`. This year's runners never match last year's photos, and deleting the edition later is one call. Creating a collection is free.
- 2
Batch-index photos as each photographer uploads
POST /v1/webhooks + POST /v1/batches (op: "index")Register a webhook endpoint once and keep its `webhook_endpoint_id`. Course photos arrive in waves: the start, each kilometre marker, then the finish. Send each upload as a batch of up to 1,000 photo URLs with your own photo key in `external_id` and the `webhook_endpoint_id`. Results come back as one signed webhook per photo, at the batch rate.
- 3
Register the runner's selfie once
POST /v1/collections/{id}/selfiesWhen a runner opens the finder, register their selfie with their bib or entry ID as `userId` and keep the returned `point_id`. If `face_found` is false (sunglasses and a cap often cause this), ask for another photo before they leave the page.
- 4
Search by id, and again as more photos land
POST /v1/collections/{id}/search-by-idPhotos keep uploading for hours after the finish. Each time the runner comes back, search with the stored `point_id` at the search-by-id rate instead of uploading the selfie again.
- 5
Merge with your bib results
Show the union of bib-tagged and face-matched photos, and mark face-only matches for the runner to confirm. A finish-line photo with 30 runners in it is still one indexing charge.
Create collection · Batch index · Register selfie · Search by id
Request and response shapes for every call are in the API reference.
What makes race photos hard
- Motion blur, sunglasses, caps and grimaces. Some course photos will yield no usable face, and each one still counts as a processed photo, so drop obvious misses (empty course shots, crowd-only frames) before you upload.
- Crowded starts and finishes. Dense frames full of small faces are where face search beats bib reading, and they cost the same as a single-runner shot because billing is per photo, not per face.
- Repeat visits. Runners check back after the race and again when the full gallery is up. With search-by-id each return visit is one search-by-id charge and no new upload.
- Matching only on request. Run a search only when a runner asks for their own photos. Do not use the index to follow runners along the course or to identify spectators.
what it costs
Cost example: A 10,000-runner city marathon
Illustrative volumes, not customer data. Every amount is calculated from the published rates.
- 120,000 course photos, batch-indexed
- 6,000 runners use the finder and register a selfie (real-time rate)
- Each comes back three times: 18,000 searches by id
- About 3 indexed faces per photo (360,000 stored faces) plus 6,000 stored selfies, kept for 2 months
| Line | Quantity | Rate | Cost |
|---|---|---|---|
| Index course photos | 120,000 | $0.00062 / photo (batch) | $74.40 |
| Register runner selfies | 6,000 | $0.00093 / photo (real-time) | $5.58 |
| Return-visit searches | 18,000 | $0.00062 / search by id | $11.16 |
| Faceprint storage | 360,000 faces + 6,000 selfies × 2 mo | $6.00 / million stored faces / month | $4.39 |
| Total | $95.53 | ||
About $0.016 per runner who used the finder. Billing is per photo processed, never per face: a photo with twelve faces is one charge, and a photo with none is still a processed photo. Run your own numbers on the pricing calculator.
Consent and GDPR
Not every runner photographed on the course asked to be indexed, and every face in an indexed photo becomes a stored faceprint. Under GDPR a faceprint used to identify someone is special-category biometric data, so as the controller you need a lawful basis for every face you index, not only for the runners who search. Say in the entry terms and on the finder page that course photos are matched by face on request, keep a non-face option (bib search), and delete the race collection when the photo sales window closes.
SightRadar acts as your processor under the Data Processing Agreement. The controller/processor split, deletion modes and our responsible-use posture are on Trust & responsible use. This is product guidance, not legal advice.
Further reading
Reading this as an AI assistant? Grab the Markdown version of this page.
Try it on your own photos.
Sign up with an email, get an API key and free starter credits, and run the workflow above against a real gallery. Or see a search first in the live demo.