Gett Commerce Partner API
API for Commerce Partners (POS, Aggregators, Online Ordering Solutions) to integrate with the Gett Network.
Data Flow
Your system is the source of truth for catalogs, store status, and order updates. Gett is the source of truth for order creation.
| Data | Source of Truth | Direction | API |
|---|---|---|---|
| Catalog / Menu | Partner | Partner → Gett | POST /catalogset-notification |
| Store Status | Partner | Partner → Gett | POST /stores/{id}/status |
| Order Creation | Gett | Gett → Partner | Webhooks (validateOrder, placeOrder) |
| Order Updates | Partner | Partner → Gett | POST /orders/{id}/status |
Integration Lifecycle
- Onboard — Register merchant stores via the self-service API
- Sync Catalog — Host CatalogSet JSON, notify Gett when menus change (pull model)
- Receive Orders — Implement webhook endpoints for order validation and placement
- Send Updates — Push order status changes as orders progress
- Manage Stores — Pause/resume stores in real-time
Authentication
Include your API key in all requests via the Authorization header using the Bearer scheme:
Code
Setup Prerequisites
- API Key — Issued during partner onboarding
- Webhook Base URL — Where you host your order validation and placement endpoints
Tags
Catalog
Catalog synchronization using a pull model. You host the CatalogSet JSON on a publicly accessible URL (e.g., S3, CloudFront), then notify Gett when it changes. Gett asynchronously downloads and processes the update.
The CatalogSet format is identical to the Marketfront API — a normalized dictionary structure with catalogs, sections, items, and modifier groups.
Best practices:
- Treat every push as a full replacement (no partial patches)
- Keep item IDs stable across updates to preserve analytics and favorites
- Validate your JSON against the schema before notifying — invalid references cause ingestion failures
Store Management
Retrieve and update store metadata such as name, phone number, description, and logo. Operating hours are managed via your CatalogSet, not these endpoints.
Store Status
Real-time store availability management. Pause a store when it cannot accept orders (equipment failure, staff shortage, peak overload) and resume when ready.
When pausing, provide a
reason and optionally a resumeAt timestamp for automatic resumption.Order Updates
Send order progress and lifecycle updates to Gett. Orders use two fields:
state— High-level lifecycle:open,completed,cancelledstatus— Granular progress withinopen:confirmed→preparing→ready→inTransit
status for progress updates within an active order. Send state to close an order (completed or cancelled). The pending status is set automatically by Gett when the order is created — you do not need to send it.
An order can be cancelled from any status by sending state: "cancelled" with a cancelReason.Order Booster Onboarding
Self-service store registration for the Gett network. The onboarding flow:
- Register —
POST /onboarding/storeswith store details and catalog URL - Catalog Pull — Gett automatically downloads and validates your CatalogSet
- Check Status — Poll
GET /onboarding/stores/{id}to track progress - Activate — Once
ready_to_activate, call activate to go live
pending_catalog → catalog_ingesting → ready_to_activate → active (or catalog_failed if validation errors occur).