Inspiration

We all get a excited when a delivery is on its way. That’s why it’s so frustrating when a package is stolen from the porch, left at the wrong house, or soaked by rain before anyone gets home. Then come the support chats, refunds, re-orders and missed items. Happens to me and to everyone at least once. It costs time and money for everyone involved: the customer, the retailer and the carrier.

Ring doorbell already sees the end of every delivery. Ring knows that a package is at the door. It doesn’t know which package it is, or whether it belongs to this house at all. The driver standing there right next to it. I wanted the doorbell to help the person at the door.

Hold the label up to the Ring doorbell: DeliveryHub confirms the right house, tells the driver your instructions, and unlocks a Delivery Box only for packages you expect. Delivery hub would be integrated with main Delivery carriers like Amazon, FedEx, USP, USPS, etc. So that when new delivery is scheduled, your Ring camera already knows about it and expects the package. (Integration is not implemented at this stage)

What it does

DeliveryHub for Ring turns the doorbell into a package checkpoint.

The homeowner lists the packages they’re expecting, each with an optional instruction for the driver. The driver just holds the label up to the doorbell, hands-free. Ring’s package-delivery motion event starts the check, so no button, app or account is needed. In about two seconds DeliveryHub reads the barcode and the ship-to address and decides: ✅ Right house: the driver hears the homeowner’s instruction for that package, and the app marks it delivered with the doorbell photo as proof. ❌ Wrong house: “Wait, this package is for 42 Oak St.” The homeowner gets an alert. ↻ Can’t read it: the driver is asked to hold the label closer. It never guesses. Delivery Box (concept): a weatherproof, lockable box by the door that keeps parcels safe from thieves and weather. It opens only for recognized packages, relocks automatically, raises a tamper alert if forced, and can be remotely unlocked by the homeowner for anything unexpected.

How we built it

Ring Partner API: signed motion_detected (package_delivery) and button_press webhooks, verified with HMAC-SHA256 and de-duplicated by request_id; media/image/download to fetch frames: on a motion event, roughly every 1.5 s for up to 10 s, stopping at the first barcode; full one-way account linking. The nonce check follows Ring’s spec exactly: $$\text{nonce} = \operatorname{Base64URL}\big(\operatorname{HMAC\text{-}SHA256}(K,\; t \,|\, \text{":"} \,|\, \text{accountId})\big), \qquad \text{valid if } \; now - t \le 600\,\text{s}$$ AWS (serverless, one SAM template): API Gateway and Lambda (webhook → async scan worker); Amazon Bedrock (Nova Lite vision) to read the address, with Amazon Textract as the automatic fallback; Amazon Polly for the driver’s voice; DynamoDB for packages, scans, box state and the audit log; S3 for photos, with a 30-day lifecycle rule; CloudFront, plus CloudWatch metrics and X-Ray tracing. Decision logic is deterministic and explainable: zxing-wasm barcode decoding, USPS-style address normalization, and a Jaro-Winkler street-name match (strict on house number, unit and ZIP). Every decision shows what it read, the home address, and why. Web app: React + Vite, with four views: the homeowner app; the Door Display, which stands in for the doorbell speaker; a Doorbell Simulator that sends the exact signed Ring webhooks through the same pipeline, including realistic doorbell photos; a live eval page anyone can rerun. Quality: 55 unit tests, plus a 120-case live eval. Dev workflow: I used the Ring Appstore Knowledge MCP server from coding agent to implement the webhook, image and account-linking specs exactly.

Challenges we ran into

A correct package announced as “wrong house.” First eval scored 97%, but all 4 errors were right-house packages reported as the wrong house. Five whys led to the cause: when the ship-to block was too blurry, our OCR parser fell back to the return address. Fixed it with three mechanisms: only addresses printed after “SHIP TO” count; OCR debris is rejected; low-confidence mismatches ask for a retry.

Wrong decisions went from 4 to 0.

A doorbell isn’t a barcode scanner. Wide-angle optics meant 1D barcodes only decoded within about 9 cm. The 2D (QR) code on Amazon-style labels decoded in every condition I tried. So the printed address decides “right or wrong house”, and the barcode is required only for the box. The driver’s hands are full. Pressing the bell while holding a parcel is awkward, so I went hands-free on Ring’s motion events. People without a label are ignored silently: nothing stored, nothing spoken, and the box is left alone. Platform gaps: there’s no API for the doorbell’s outdoor speaker, no public simulator or sandbox access, Polly has no neural voices in our Region, and our Bedrock daily token quota was applied at 0. I built around each one (Door Display, our own simulator, voice fallback, Textract) and documented them in a friction log.

Accomplishments that we're proud of

On 120 signed webhooks through the live stack: accuracy = 114/120 = 95%, wrong decisions = 0, false confirmations = 0 The other 5% asked the driver to try again, which is the safe outcome. Latency from the Ring event to a decision: 1.9 s p50 and 2.4 s p90. Accuracy was 100% within ≈ 12 cm of the lens.

What we learned

Read the platform’s own docs through MCP. The details (nonce encoding, ±10 s frame tolerance, a mandatory sign-in) were exactly where our first guesses were wrong.

What's next for Ring DeliveryHub

Test on a real doorbell, then go through Ring Appstore certification. Use the doorbell’s outdoor speaker as soon as Ring opens it up. A Delivery Box hardware partner on AWS IoT Core and Amazon Sidewalk. An apartment and front-desk mode. Carrier APIs, so the confirmation flows back before the truck leaves.

Built With

Share this project:

Updates

Submission history