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.
Portal native entry requires a fresh server-selected purpose-bound proof for the exact RESERVATION, WAITLIST or PREORDER and original audience. An actual consumed reentryChallengeId can bind the current session contact proof; the client cannot infer it from login time. receipt is an immutable acknowledgement while current.manageToken is independently nullable. /guest-portal/reentry-context is a private POST command, never cached profile metadata. Dedicated initial QR reentry requires both tableGuestToken and guestPortalToken; booking preparation and association support table-only or both.
Public presentations and native guest grants
Storefront reads need no credential and expose only published content and safe current venue data. A public handle, hostname, connectionId or QR locator is a discovery value. None replaces the native guest credential for the selected resource.
QR admission returns a private requestToken for one join; claiming an approved join returns a separate table-session capability. Send the appropriate token as Bearer only to its documented native operation. Observer baseline and ticket commands instead accept the current PREORDER, RESERVATION, WAITLIST or TABLE_SESSION READ capability in their JSON body. Read the snapshot and cursor first, request a separate one-use ticket and require matching scopeBinding; native WebSocket qualification is pending.
Native guest presentation checks use the actual request Origin. Browser clients let the browser supply it and use credentials: 'omit'; they must not attach account cookies, staff authorization or CSRF headers as fallback. Operations that declare x-hallify-connection-id use it as a nonsecret connection locator; QR locator resolution uses its documented connectionId query parameter. Neither rewrites the presentation binding captured by an issued guest grant. Keep capabilities and tickets in the owning flow's memory, outside Redux, URLs, cookies, logs, analytics and error payloads.
For isolated widgets, bootstrap runs inside the frame and resolves its exact verified parent binding, frame/API origins and current mode. New demand carries storefrontWidgetContext as x-hallify-widget-context; it is separate from native draft/manage/membership/payment credentials. ACTIVE can issue short-lived presentation proof; DISABLED can return CONTINUATION_ONLY with null discovery/proof. Existing grants retain their original authority and deadlines. Neither proof nor native credentials enter parent messages or public URLs.
Reservation verification and agreement authority
guarantee-offer and read-intent declare public access. Offer terms/digest grant no booking or payment authority. read-intent is scoped to the exact native channel, original request fingerprint and current Origin/presentation; it returns only redacted verification state. Do not add an invented intent token or use a guessed identifier to recover management access.
For a staff-proposed CHANGE/RESTORE, challenge starts real verification of the existing guest contact. verify sends the original challenge capability and actual code in its JSON body; only matching verified native identity receives the frozen proposal and a separate acceptance capability. accept sends that acceptance capability and exact planHash in its body after explicit consent. These credentials are bound to the proposal, actual Origin, request fingerprint and fixed deadline, and are distinct from a manage Bearer grant or payment access.
Keep contact values, codes, challenge/acceptance/manage capabilities and private receipts inside the owning flow, outside URLs, cookies, global state, logs and analytics. Preserve each original command key/body and its issued deadline; retries do not grant fresh proof. Protected staff forfeiture and guarantee-credit operations cannot be called with any guest credential.
Native guest payment access
Payment admission accepts a current QR_MEMBERSHIP, PREORDER_MANAGE or genuine RESERVATION_MANAGE capability in its private JSON body, with the actual source Origin. Reservation entry addresses the exact native reservation and guarantee, not a waitlist or proposed agreement. The returned payment-access capability is separate from observer tickets, join, draft, partner and account credentials. The access UUID is nonsecret and grants no authority by itself.
Open-access, issue-handoff and redeem-handoff use body credentials. Bill, quote, consent-offer, checkout creation, command recovery and checkout progress/recovery use the separate guestPaymentAccessToken Bearer scheme. Keep all credential-bearing bodies and private responses outside Redux actions/caches; the generated private-command builders are not ordinary cached endpoint hooks. Do not add a duplicate Authorization transport argument or an account/CSRF fallback.
Cross-origin handoff starts on the receiver: it saves its own raw capability and returns only its SHA-256 digest and correlation. Source/native and receiver capabilities never cross foreign origins. Only the receiver-bound private handoff travels in the deliver POST body. Pending receiver context remains UNVERIFIED until current native/presentation authority passes backend issue and redeem; URLs carry only nonsecret context.
Each request must match the access's exact current transportOrigin. Browser clients omit cookies, keep private responses no-store and reject API redirects. Source and receipt deadlines remain original through handoff or access rotation; the at-most-twenty-four-hour own-receipt window is not the fifteen-minute financial window and cannot authorize fresh spending.
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.