External Orders API 2.0
External Orders API 2.0
Link connects PAR’s ordering platform to your marketplace (MP).
Flow overview
| # | Area | Event | Summary |
|---|---|---|---|
| 1 | Onboarding | Authenticate | OAuth client credentials → Bearer token |
| 2 | Store | Store connected | Link → MP: map Link venue_id to your storefront |
| 3 | Store | Store disconnected | Link → MP: stop new orders; complete in-flight as agreed |
| 4 | Store | Store paused | MP → Link: POST /stores/{storeId}/status · Link → MP: store.status_changed webhook |
| 5 | Store | Store resumed | Same paths as pause — status: Online |
| 6 | Menu | Menu published | Link → MP: fetch full menu from menu_url |
| 7 | Menu | Menu unpublished | Link → MP: remove menu from your catalog |
| 8 | Order | New order | MP → Link: submit order for the restaurant |
| 9 | Order | Order confirmed | Link → MP: restaurant accepted; prep time included |
| 10 | Order | Order rejected | Link → MP: restaurant rejected; reason included |
| 11 | Order | Order ready | Link → MP: ready for pickup / hand-off |
| 12 | Order | Order cancelled | MP ↔ Link: stay aligned on cancel state |
Order lifecycle
States are driven mostly by notifications between MP and Link (restaurant actions flow through Link).
| # | State | Side | What happens |
|---|---|---|---|
| 1 | PENDING / INIT | MP | MP sends new order to Link; restaurant sees it |
| 2a | CONFIRMED / SENT | Link | Restaurant accepts; Link notifies MP with prep time |
| 2b | REJECTED | Link | Restaurant rejects; Link notifies MP with reason |
| 3 | IN PREP | Link | Kitchen preparing; Link may adjust ETA toward MP |
| 4 | READY | Link | Order ready for pickup or hand-off |
| — | CANCELLED | MP ↔ Link | Either side can initiate; rules depend on stage |
Outbound webhooks (Link → MP)
Link delivers event notifications to your HTTPS webhook URL (webhook_url) configured
on the PARLink integration (venue → brand → channel defaults in Core). Each request is a
POST with Content-Type: application/json.
Headers on every delivery
| Header | Description |
|---|---|
X-Webhook-Signature |
sha256=<hex> — HMAC-SHA256 of the raw JSON body using your webhook_signing_secret |
X-Idempotency-Key |
UUID — unique per delivery attempt; use for deduplication |
Retry: One synchronous attempt, then up to 5 queued retries with exponential backoff (1s, 2s, 4s, 8s, 16s). Respond with 2xx to acknowledge.
Verify signatures: Recompute HMAC-SHA256 on the raw request body and compare to
X-Webhook-Signature (constant-time compare).
See tag Webhook Events for payload schemas. Configuration is covered under Webhooks.
Priority & sequencing
Phase 1 — Foundation
| Area | Why |
|---|---|
| Authentication | Required for every call |
| Webhook URL + signing secret | Required before Link can notify your MP |
| Store connect / disconnect | Mapping before menus or orders |
Phase 2 — Primary order path
| Area | Why |
|---|---|
| Menu push to MP | Menus before orders |
| New order | Inbound traffic |
| Confirm / reject | Restaurant decision back to MP |
| Ready | Dispatch-critical |
Phase 3 — Full lifecycle
| Area | Why |
|---|---|
| Pause / resume store | Operational control |
| Cancel order | Exceptions |
Phase 4 — Polish
| Area | Why |
|---|---|
| Store status read | Support / reconciliation |
| Menu pull on demand | Recovery and audits |