Partner keys
Partner preorders use Authorization: Bearer <key>. The administrator creates a key with catalog:read, quotes:write, orders:write, orders:read and/or webhooks:manage. It is limited to one venue and selected sales channels, may expire, and can be rotated or revoked. The secret is returned once. An active public preorder channel is also required.
Guest and candidate access
Reservation and preorder management use Bearer capabilities bound to a specific record. The Guest Portal uses x-guest-portal-token after a one-time bootstrap exchange. The Candidate Portal uses Authorization: Candidate <token>. A public handle or posting slug identifies a resource but is not a credential.
Guest Portal and preorder bootstrap grants delivered in a URL fragment must be exchanged by the owning guest flow. Do not place tokens in query strings, logs, analytics or global application state. Respect revocation and expiration.
Signed integrations
External orders, audit, workforce, guest communications and payment callbacks each have a registered HMAC profile. They differ in timestamp format, body canonicalization, secret decoding, signature encoding and replay behavior. Bank callbacks use provider-specific verification instead of this shared header protocol.
Existing Hallify settings
Administrative setup uses the signed-in Hallify account and its organization/venue permissions. Account sessions use HttpOnly cookies and the documented CSRF handshake; they reject Authorization bearer credentials. A partner key is not interchangeable with a staff session and cannot access every Hallify module.