For developers

A developer wires a shop or a till to Delieta through Partner API v1. The tenant comes from the key. The request never sends companyId or tenantSlug. Money is whole grosz; the only v1 currency is PLN.

Issue a key

In the panel: Settings → Integrations. The plaintext key is shown once. Format: dlt_live_… or dlt_test_….

• A secret key (orders:write, eta:quote) lives on the server. Never in the browser, never as NEXT_PUBLIC_.
• A publishable key has only catalog:read. It may go into a static shop because it cannot read anything private.

A test key reads the same catalog as live, but will not create an order (test_key_readonly). POST /api/v1/orders needs dlt_live_….

Read the menu, then a quote, then an order

Three calls, in this order, close the shop loop:

1. GET /api/v1/menu — catalog of the key’s company. Scope catalog:read.
2. POST /api/v1/quotes — a minute window to an address. Scope eta:quote. Always a range, never a guarantee.
3. POST /api/v1/orders — a ticket to the kitchen. Scope orders:write. The Idempotency-Key header is required.

The 201 response carries order.trackingUrl. That is the link you give the customer — the /o/… page. Do not invent a second tracking URL.

Read whether the kitchen accepted

If the company requires acceptance, a new ticket starts in pending_acceptance. State is changed by a person or a time limit — not your backend. That is why GET /api/v1/orders/{id} exists: it spends the read budget, not the create budget.

Storefront contract, not a webhook

A static shop (Next export) bakes the menu at build and keeps a cart of { itemId, quantity }. That is the storefront contract. Delieta does not host that shop.

There are no order-status webhooks. Poll GET.

Full reference, matching GET /api/v1/openapi: Partner API.