Authorization header:
Getting a key
The event organiser issues it from the VENTRY dashboard, under API / Integrations. When creating it they choose:- Scopes: what you can read and write.
- Restrictions: whether the key is limited to certain ticket types or days.
- Rate limit per minute.
- Allowed IPs, if they want to restrict where it can be used from.
Keys with write scopes
Any key requesting a write scope is created disabled and responds:Scopes
Calling an endpoint without its scope returns
403 insufficient_scope.
Key format
vk_live_ prefix is not decorative: it lets secret scanners on GitHub and
similar services detect a key published by mistake.
Best practices
Treat it as a server-side secret
Treat it as a server-side secret
A VENTRY API key can read attendees’ personal data and, depending on its
scopes, write to the event. Never embed it in a mobile app, in browser
JavaScript or in a repository. If your door application needs to accredit,
have it talk to your backend and let the backend call VENTRY.
Ask only for the scopes you use
Ask only for the scopes you use
If you only push tickets, ask for
event.read and tickets.write. The fewer
the scopes, the less damage a compromised key does.Use restrictions
Use restrictions
If you only handle one ticket type, ask the organiser to restrict the key to
that type. It then becomes impossible to touch tickets that are not yours by
mistake.
Rotate without downtime
Rotate without downtime
There is no automatic rotation. To rotate without interrupting service: ask
for a new key, deploy it, verify it works with
GET /ping, and only then ask
for the old one to be revoked. A revoked key stops working immediately.Log the request_id
Log the request_id
Every response carries the
X-Request-Id header. Store it in your logs: it is
what lets VENTRY support find your exact request.