SightLine

Your business event, on camera, within minutes.

Comment

Inspiration

We run 27 unattended vending units, each watched by a Ring camera. When the point of sale records a sale, we want the footage around it, to tell whether more left than was paid for. Every vision system we evaluated was closed: proprietary cameras, proprietary software, no API to send an event and get footage back. Rather than replace 27 working cameras, we built that bridge on Ring. When we presented the idea at NAMA this year, none of the vendors we met believed Ring could do it.

What it does

SightLine is a business-system integration for Ring: an event-driven Ring camera pipeline that a point of sale, door controller or scheduler drives with a site event: one call starts the capture, and the door unlock, the door close and the end of the sale are three more small calls.

  1. A business system posts a site event: "a sale started at site A".
  2. SightLine finds the right camera from the operator's site-to-camera assignment.
  3. It makes the camera record, at once. Ring cameras record only during motion or a live session, so SightLine opens a WHEP live session and pulls the RTSPS stream with ffmpeg: a still every 5 seconds and the clip. The door unlock and close reported later extend or end the recording, so the footage covers the whole interaction and nothing else. The next live session opens before Ring's sixty-second cap, so a visit stays one continuous recording.
  4. It cuts the removal frames. After the door window closes it finds the door-opening, product-leaving and door-closed frames and stores them with a manifest that says what it could and could not see: an obscured lens, a recording gap, a door that opened off camera.
  5. It hands the evidence back. One GET returns the event with its stills, clip and key frames; signed webhooks tell the business system when each is ready; an operator page shows every camera and every event.

Two verification mechanisms matter in practice. Ring re-serves cached stills under a fresh timestamp watermark, so freshness is judged by scene signature, not bytes. When the live stream drops mid-event, SightLine fetches Ring's own recording of the moment, aligns it to the live footage frame by frame, and scores the stills it archived inside the hole, so a hole is reported with the evidence that exists rather than as silence.

A tenant can be served every still and clip with people pixelated by an on-host YOLOX detector while the original stays with the operator as evidence; the judge demo works this way.

The software is multi-tenant (API keys, camera assignments, media and webhooks per business) and runs hosted at api.sightlineview.com on Azure; today its tenants are our own and the read-only judge demo.

How we built it

  • Ring developer API, directly. Partner-initiated account linking at oauth.ring.com, then api.amazonvision.com/v1: devices with status and capabilities, event history with cursor paging, image and video download, WHEP live sessions. No third-party Ring libraries.
  • .NET 8 library and ASP.NET host: capture planner, event windows, removal-frame detector, AES-GCM token protection, proactive refresh with edge-block awareness; SQLite and local files when run locally, Azure SQL and Blob Storage hosted. ffmpeg for the live pull and frame cutting. Angular 18 operator page.
  • A public API reference at api.sightlineview.com/docs, generated from the code (OpenAPI), with a quickstart of the calls a point of sale makes (one starts the capture; a door sale is four in all).
  • An MCP server (mcp/, TypeScript) so an AI agent can walk a business through connecting to SightLine: it guides the owner through linking Ring, assigns cameras to sites, creates keys, runs a visit and reads back the verdict.
  • 700-plus test cases, including Ring API contract tests against fake handlers and real-ffmpeg stream tests, run by GitHub Actions on pushes to main and on pull requests.

Challenges we ran into

Linking is partner-initiated and nothing like a normal OAuth flow; our first link failed blind for six days. The snapshot endpoint returns cached stills, so "take a picture now" became "open a live session and consume it". Live sessions end at about sixty seconds without notice, and a stream that stalls is left open with no media. SightLine now detects the stall, fetches Ring's own recording of that window and labels the gap on the verdict instead of guessing. Twenty-one of these, each with its fix or workaround status, are in the submission's friction log.

Accomplishments we're proud of

It runs in production across the fleet. Since 20 October our point of sale forwards every sale at all 27 Ring-watched vending units to the hosted service. In the first six hours: 63 sales from 16 sites, 46 of them door sales. (The other 17 never unlocked a door: 6 were closed by the point of sale within 6 to 32 seconds, taps that did not complete, and 11 got neither a close nor a door report and timed out at 30 minutes.) Of the 46, the camera caught the opening on video for 28, found the door already open when video resumed for 2, saw it stay shut for 8, lost the moment to a Ring stream gap on 6, and failed on 2, both on an unreadable clip (fixed the same night; one of the two was also at a camera that streams nothing). Verdicts land 3 to 18 minutes after the sale, typically about 6, reviewable from a phone.

What we learned

A Ring camera is a sensor that records on demand, not a CCTV recorder. Design around live sessions, verify freshness, and treat every Ring answer as a contract to test against.

What's next

  • A Ring Appstore listing, so any operator can link their own Ring account.
  • Shrink scoring as a service: a scorer that reads each sale's frames and flags likely shrinkage.
  • Multi-camera stitching, and self-serve sign-up at sightlineview.com.

Built With

Share this project:

Updates

Submission history