Veyla · Developers

The scan webhook.

Last updated 8 August 2026

Veyla Protect watches a door and catches what shouldn't happen — tailgating, doors held open, entries with no scan. To do that well it wants to know when a credential was presented and whether it was accepted. If your access-control or member system can tell us that, this one endpoint is all you need. No bespoke integration, no SDK.

The endpoint

Send one POST per scan, as it happens:

POST https://app.veyla.com.au/api/integrations/scan
Authorization: Bearer <your integration token>
Content-Type: application/json

The token is minted per site when Veyla connects your system — it is the whole credential, so keep it secret and send it only over HTTPS.

The body

{
  "event_id":    "a-unique-id-for-this-scan",   // required
  "occurred_at": "2026-08-08T09:37:52+10:00",   // required, ISO 8601
  "result":      "granted",                     // required: granted | denied | unknown
  "member_ref":  "12345",                       // optional: your member id
  "member_name": "Jess M.",                     // optional
  "door_ref":    "front"                        // optional: which door/gate
}

Only three fields are required. A system that can only say “a scan happened” still helps — send event_id, occurred_at and result and leave the rest out.

The fields that matter most

result — send denied for scans your system rejected, not just the successful ones. Denied scans are how Protect tells a genuine tailgate from a member who simply scanned again; a granted-only feed is far less useful.

occurred_at — the moment of the scan, not the moment you send it. Second precision or better. Sooner is better: scans that reach us within a few seconds correlate best against what the camera saw.

event_id — anything unique and stable for the scan. If you retry a delivery, reuse the same id and we treat it as one event — safe to send more than once.

What you get back

200 OK
{ "ok": true, "deduped": false }

deduped: true means we’d already recorded that event_id — no harm done. A 401 means the token is wrong or missing; 400 means a required field was absent or the timestamp didn’t parse. We answer immediately, so it’s safe to call us inline from your own webhook handler.

A note on what we don't ask for

No billing data, no payment methods, no documents — nothing beyond the fields above. Biometrics never travel this endpoint and never touch your system. The less we hold, the less there is to protect; that’s deliberate. See our security page for the full picture.

Getting a token

Tokens are issued by Veyla when your system is connected to a site. If you’re an access-control vendor, a member-management platform, or an integrator who wants to feed Veyla, email dev@veyla.com.au and we’ll set you up.