← all use cases

Theme park ride-photo matching with face search

A guest opts in once at the gate, and every ride photo they appear in is waiting in the app or at the exit kiosk.

Attractions are the one photo vertical where minutes matter. A guest steps off the ride and walks past the photo counter within a minute or two, so photos have to be searchable before they get there. That makes this the vertical for real-time indexing, and for short-lived collections that are emptied after each day.

Who builds this: Theme parks, water parks, zoos, ski resorts and attraction operators, and the photo-system vendors that run their capture points.

the workflow

How it goes together

  1. 1

    One collection per park per day

    POST /v1/collections

    For example `park-north-2026-10-27`. A guest's photos only match within the day they visited, and one delete removes the whole day's faceprints.

  2. 2

    Index each capture in real time

    POST /v1/collections/{id}/index

    On-ride cameras post each photo synchronously with your capture ID as `photoId`, and its faces are stored in the collection by the time the call returns. That is the real-time rate, which is the right choice here. Batch is for work that can wait.

  3. 3

    Opt guests in at the gate or in the app

    POST /v1/collections/{id}/selfies

    Guests who want ride photos register a selfie against their ticket or wristband ID. Guests who do not are never matched.

  4. 4

    Look up the guest's photos

    POST /v1/collections/{id}/search-by-id

    At the exit kiosk or in the app, search by the guest's stored `point_id`. Each refresh is one search-by-id charge, and the kiosk does not need to capture a new image.

  5. 5

    Empty each day's collection

    DELETE /v1/collections/{id}?immediate=true

    Once the purchase window closes (the same day, or a few days for app sales), delete that day's collection. Purchased photos live in your own storage. The faceprints do not need to.

Create collection · Real-time index · Register selfie · Search by id · Delete collection

Request and response shapes for every call are in the API reference.

What is different about attractions

  • Speed matters more than price. Real-time indexing costs more per photo than batch, but a ride photo that shows up after the guest has left the exit is a lost sale.
  • Every rider is indexed, not only buyers. Each ride photo puts every face in the car into that day's collection. Keep collections to one day, delete them promptly, and put up signs at capture points.
  • Opt-in replaces the card scan. One selfie at the gate replaces linking a photo to a card at every ride. Guests who skip it still buy photos the usual way.
  • No tracking across days or around the park. Do not use the index to follow guests around the park or to recognise them on a later visit. Per-day collections make that hard by design, and the Terms prohibit unlawful surveillance and tracking.

what it costs

Cost example: One busy day at a mid-size park

Illustrative volumes, not customer data. Every amount is calculated from the published rates.

  • 15,000 ride and attraction photos, indexed in real time
  • 2,500 guests opt in with a selfie at the gate (real-time rate)
  • Four lookups per opted-in guest across the day: 10,000 searches by id
  • About 4 faces per photo (60,000 stored faces) plus 2,500 stored selfies, deleted after 3 days (0.1 month)
Cost breakdown for One busy day at a mid-size park
LineQuantityRateCost
Index ride photos in real time15,000$0.00093 / photo (real-time)$13.95
Register guest selfies2,500$0.00093 / photo (real-time)$2.33
Kiosk and app lookups10,000$0.00062 / search by id$6.20
Faceprint storage60,000 faces + 2,500 selfies × 0.1 mo$6.00 / million stored faces / month$0.04
Total$22.51

About $0.009 per opted-in guest. 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.

Ticket terms alone are a weak basis for indexing every rider's face. Make photo matching a separate opt-in at the gate or in the app, post signs at each capture point, and keep the day's collection only as long as the purchase window. Guests who do not opt in should be able to buy their photos without a face match. Illinois (BIPA) and several other jurisdictions add written-notice and retention rules on top of GDPR.

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.