Prerequisites
- Seller or buyer role in an approved organization
- Order scopes for the target market
- Catalog source mapping (see Inventory & Catalog)
- Approved non-production environment for testing
Order & Booking Integrations
Order & Booking Integrations
Design connected order and appointment journeys with explicit states, approvals and evidence.
Orders
line-level acceptance and fulfillment
Bookings
confirmed only by the provider
No blind retries
look up before you resend
Choose a transaction type
Orders and bookings work differently
Know which one you're building before you start. There's no shared universal endpoint for both.
An order covers one or more lines from an authorized seller. Each line is accepted, fulfilled or rejected on its own evidence.
- 1QuotePrice, tax basis, currency and expiry
- 2RequestYour request is received — not yet an order
- 3Seller acceptanceOrder and each line accepted
- 4PaymentConfirmed by the payment source
- 5FulfilledShipment or delivery evidence recorded
Exception paths
- Partially accepted — some lines rejected
- Payment uncertain — check with the processor
- Quote expired — re-quote before continuing
Business objects
How the pieces relate
A simplified model. Each object has its own owner and status.
Text alternative to the diagram
| Object | Belongs to | Authority |
|---|---|---|
| Order | Buyer and seller | Seller's commerce system |
| Order lines | An order | Seller, line by line |
| Payment | An order or booking | Authorized payment processor |
| Fulfillment | Order lines | Transport or delivery evidence owner |
| Booking | A provider site | Provider booking system |
| Slot hold | A booking request | Provider capacity — only if supported |
Readiness
Explore integration requirements
Integration access depends on partner eligibility, market and approved capabilities.
Seller
Accepts and fulfills orders.
Buyer
Places orders from an approved system.
Service provider
Confirms appointments at its sites.
Fleet operator
Books services for its vehicles.
Capability by market
| Market | Orders | Bookings |
|---|---|---|
| United Kingdom (your market) | Pilot | Pilot |
| United States | Not confirmed | Not confirmed |
| Germany | Not confirmed | Not supported |
| Other markets | Not confirmed | Not confirmed |
Demonstration registry · source-versioned · unknown is not universal coverage.
Stock, slots & payment
Who decides what
Stock and slots
Availability is read-only evidence from its source. It isn't a reservation, and no hold duration is promised.
Payment
Authorization, capture, settlement and refunds are confirmed by the authorized payment source — never by a generic paid badge.
Booking confirmation
Only the provider confirms an appointment. An unconfirmed request is not a booking.
Changes, cancellations & events
When things change after a request
Cancellations and refunds
Cancellation approval and money returned are separate steps that progress independently. If no supported rule applies, contact support.
Partial orders
Successful lines keep their outcome; failed lines are listed explicitly. One line never completes the whole order.
Events and reconciliation
Use webhooks for change notifications and read endpoints to reconcile. Late, duplicate or out-of-order events are expected — exactly-once delivery is never assumed.
WebhooksSafe retries
Look up before you retry
Every request carries an idempotency key. The same key with the same details returns the same outcome. A changed payload is rejected, so retries never create a second transaction.
Try it — simulationSynthetic
idem_0001Examples
Synthetic request and response
Supported operations and schemas are in API Documentation. Check Platform Status before reporting an outage.
FAQ
Order & Booking Integrations questions
An order concerns purchasing goods or an approved procurement service with line and fulfillment states; a booking is a request for a provider-controlled appointment or capacity slot. Their acceptance, change and completion rules differ.
No. A received request isn't an order until the seller accepts it, line by line.
No. Only the provider confirms an appointment. A slot hold, where supported, is temporary and not a confirmation.
No. Access depends on partner eligibility, market and the capabilities approved for your organization.
Orders and bookings are in pilot in some markets only. Check the capability table above for your market.
Availability is read-only evidence. It doesn't reserve stock, so a line can still be rejected when the seller reviews it.
As a time with the provider site's time zone. Always show it in the site's local time, not the user's device time.
Send an idempotency key with every request, and look up the outcome by key before you retry.
No. Payment states come from the authorized payment source and move independently of order and line states.
Yes, where your organization is approved for those event families. Reconcile with read endpoints as well.
Use the event time and the resource's current state from a read endpoint. Never assume exactly-once or ordered delivery.
Yes. Accepted lines keep their outcome and rejected lines are listed explicitly.
Only where the provider supports it. A reschedule is a new proposal the provider has to confirm.
Cancellation approval and any refund are separate steps that progress independently.
A timeout means the outcome is unknown. Look up the request by its idempotency key before sending it again.
Request IDs, timings and status codes. Never log secrets, payment details or more personal data than needed.
Platform Status shows current and historical component status.
API Documentation lists supported operations; Security & Integration Guidance covers keys, secrets and data handling.