What the API covers
The Dukan merchant API exposes the same store the dashboard and the Manager app work with: products, categories, brands, collections, homepage sections, orders, analytics, and the store's own details.
It is the seam for the integrations shops actually ask for — pushing a supplier's price list in, pulling orders into an accounting system, or syncing stock with a warehouse you already run.
Base address
https://dukan.biz/api/merchant/v1
Every path in this guide is relative to that address, and every response is JSON.
Get an API key
Open Settings, then Developers, and create a key. Give it a name that says what it is for, so a key can be retired later without guessing what it will break.
A key is shown once, at the moment it is created. Copy it then; if it is lost, delete it and issue another.
Authenticate a request
Send the key as a bearer token:
Authorization: Bearer YOUR_API_KEY
Accept: application/json
A key belongs to one store and carries the permissions you gave it. Requests for another store are refused rather than silently returning nothing.
Make a request
GET /products?status=published&limit=50
GET /orders?status=new
GET /analytics?from=2026-08-01&to=2026-08-31
Lists are paged, and every list response carries the cursor for the next page. Follow the cursor rather than counting pages — a catalog changes while you are reading it.
Write to the store
POST, PATCH and DELETE cover the same ground: create and update products and their variants, move an order to its next stage, edit categories, brands and collections, and replace the homepage section list.
Money is sent and returned in minor units as whole numbers, never as decimals, so nothing rounds on its way through your integration.
Webhooks
Register a URL and Dukan posts to it when something happens in the store — a new order, an order changing stage, a product going out of stock.
Each delivery is signed, so verify the signature before acting on the body. Answer with a 2xx quickly and do your work afterwards; a delivery that is not acknowledged is retried with a growing gap between attempts, so your endpoint should treat a repeat of the same event as the same event.
Rate limits
Requests are limited per key. Every response carries your remaining allowance in its headers, and a request over the limit comes back as 429 with the number of seconds to wait.
Read a list once and cache it rather than polling. For anything you need promptly, use a webhook instead of a loop.
Errors
Errors come back with the right HTTP status and a JSON body naming the field at fault:
401— the key is missing, wrong, or revoked.403— the key is valid but not permitted to do this.404— no such record in this store.422— the request was understood but a field is invalid; the body says which.429— too many requests.
Versioning
The version is in the path. Additive changes — a new field, a new endpoint — happen inside a version, so write clients that ignore fields they do not recognise. Anything that would break an existing client gets a new version and a migration window.
Get developer support
Email [email protected] with a short description of the system you want to connect, what you have tried, and the request and response you are stuck on.