Inspiration

Every event we've run or attended has the same bottleneck at the door: a line of people fumbling for a QR code or a name on a clipboard. Meanwhile most venues already own a camera that could do this automatically — a Ring doorbell or security cam. I built Eventry to use Ring's webhook/WHEP pipeline plus AWS Rekognition to turn hardware people already have into a zero-friction, opt-in face check-in system, without forcing organizers to buy anything new.

What it does

Eventry is an event management platform — ticketing (Stripe/Paystack), organizer dashboards, team check-in tooling — built around one new flow: an attendee opts in with a single selfie during registration, Rekognition turns it into a face vector scoped to that one event (never stored globally), and when they walk up to a Ring device at the venue, a signed webhook fires, we pull the frame, match it, and auto check them in with a chime. No badge, no scanning, no line. A QR badge still exists as a fallback for anyone who skips the selfie.

How it was built

React/TypeScript/Vite frontend (Amplify-hosted) talking to a Laravel 11 API (Lightsail: nginx, PHP-FPM, Postgres, Redis) over Sanctum auth. Ring webhooks are verified with HMAC-SHA256 and must ack within 5 seconds, so we built a RingCredentialResolver for multi-tenant device/Playground fallback and pushed anything slow — like Bedrock-generated arrival captions — onto a queued job outside that window. Rekognition gets one Face Collection per event (event-{id}), IndexFaces keyed by enrollment id (not user id) on opt-in, SearchFacesByImage against the captured frame at check-in, threshold tuned empirically to 92. Assets live in S3 after a mid-hackathon migration off Backblaze B2/Cloudflare R2 to consolidate on one AWS stack.

Challenges encountered

Ring's own sample code only documents the simplified Playground bearer-token check, not the production HMAC signature path, so we reverse-engineered that from the webhook payload spec. The 5-second ack window forced real architectural discipline around what can run inline vs. async. Ring's Playground virtual device only plays Ring's own canned footage with no way to feed it a real face — so we built a laptop-webcam fallback (getUserMedia + client-side QR decode) directly into the check-in kiosk to exercise the full match pipeline without physical hardware. On the infra side: a stale OPcache silently kept serving an old CACHE_DRIVER after a config change, the smallest Lightsail tier OOM'd under normal PHP-FPM worker counts until we added a swapfile, and a missing php8.3-gd extension broke floor-plan image uploads in production with an opaque driver error.

Accomplishments that i am proud of

A privacy story i can actually defend, not just claim: per-event face collections can be purged completely after an event ends, so "we never kept your photo, only a vector, and now it's gone" is literally true. We also shipped a dev-mode escape hatch (webcam check-in) that makes the whole face-match pipeline testable by anyone, with or without real Ring hardware — not something the hackathon required, but something that made our own development dramatically less painful.

What was learnt

Hard external deadlines (Ring's 5s ack) make you design for async a lot sooner than you'd otherwise bother to. Also: "it deploys successfully" and "it works" are different claims — several of our worst bugs (stale OPcache, missing GD extension, wrong S3 CORS policy) failed silently rather than loudly, and only showed up as a user-facing error much later.

What's next for Eventry

Multi-face arrivals (group check-in from one frame), organizer-configurable match thresholds per event instead of one global default, and pushing the webcam dev-mode idea back to Ring as a real Playground feature request — let developers attach a laptop camera as a virtual device's video source.

Built With

Share this project:

Updates

Submission history