Choose your workflow
Choose partner preorders for server-to-server catalog and preorder creation. Use external order ingress to deliver orders from another system. Guest interfaces use personal capabilities and contact verification instead of a restaurant-wide API key.
Published storefronts expose reviewed presentation content, explicitly attached venues and nullable native ordering discovery. Guest pickup/delivery ordering follows that exact channel to its published menu/configurator/cart, ASAP or scheduled timing, draft/contact verification, frozen quote acceptance and original management. Origin allowlisting remains a separate native prerequisite. QR table access uses its own join/claim lifecycle; guest observers use current resource READ authority rather than ordering or payment authority, with native WebSocket qualification still separate.
Reservation booking selects native availability, reviews an exact server guarantee offer and accepts its digest before intent creation and real contact verification. Keep original receipts separate from current intent/manage state. Staff-proposed financial CHANGE/RESTORE needs the existing guest’s verified contact and explicit exact-plan acceptance; actual disposition and activation remain separate.
Use the JS/TS SDK for selected Guest PRO methods, or mount an isolated reservation, preorder or table widget. A widget requires its exact verified parent binding and stable public slot. Bootstrap and the owning native flow supply current resources and credentials. Node partner Preorders use a separate four-method Bearer client.
Choose native payment only with the correct source authority
Guest payments begin with current QR_MEMBERSHIP, PREORDER_MANAGE or genuine RESERVATION_MANAGE authority, native payment eligibility and an eligible merchant binding. Bill payments and reservation guarantees have distinct selection shapes and server-derived capture modes. Review the exact legal payee, amounts and financial offer, then require explicit immutable consent. A storefront view, join request, draft, proposal ID or observer ticket cannot replace this admission.
Use the configured canonical checkout origin and receiver-first handoff for ordinary cross-origin headless flows. An isolated widget uses its private prepare/claim transition before ordinary handoff redemption. Retain the original command through reload, return and UNKNOWN; read-only receipt/progress recovery never means another payment. Courier integration, deployed artifacts and live PSP qualification remain separate.
Prepare access
Ask the restaurant administrator to select the organization and venue in Hallify, enable the appropriate channel or provider connection, and grant only the required permissions. Credentials must be issued through the existing settings. A storefront additionally needs a published revision, an active HOSTED connection and current verified host authority. Reading these pages does not create a credential or publish a restaurant.
Make the first request
The public server-to-server API base URL is https://api.hallify.co. The site’s /api proxy is application infrastructure, not a separate integration API. Configure only a test venue explicitly approved by its owner for your initial requests; this documentation does not provision a sandbox.
Open the first operation from your guide, read its prerequisites, copy cURL or the Node.js TypeScript example, and replace synthetic identifiers with values obtained from Hallify. For browser guest requests, follow the guide's credentials: 'omit' and browser-managed Origin rules. Check HTTP status before using the response body. Sample identifiers, tokens, dates and replies are illustrative, not live resources.
Continue reliably
Store partner keys and HMAC secrets on your server. Keep private guest capabilities and observer tickets in their owning guest flow, outside URLs, logs, analytics and global application state. Retain returned references, revisions and expiry timestamps. Reuse an idempotency key only for a retry of the same command. Handle expiration, conflicts and webhook replays according to the selected contract.