Skip to main content

Changelog

The API is in pilot and Enterprise-only: keys must be pilot-enrolled and belong to a store on an active Enterprise plan, or every call returns 403, and https://api.dzbuild.app is the only supported host.

v1.4 — 2026-09-05 (pilot)​

  • ✨ Orders can be written. POST /v1/orders creates an order, PATCH /v1/orders/{id} moves its status, POST /v1/orders/{id}/cancel cancels it, and POST /v1/orders/{id}/send-to-delivery hands one parcel to the store's courier. The two new scopes are orders:write and delivery:send.
  • ⚠️ Scopes are frozen at mint time, so an existing key does not gain the new scopes: issue a new key, or reconnect the connector, to use them.
  • ⚠️ A courier send always needs a server-issued confirmation. The first call answers 409 confirmation_required with a single-use token and a summary naming the customer, phone, destination, total and courier; only that token sends the parcel. A confirm: true in the body is not accepted for this endpoint, from any caller. An order already sent is refused with 409 already_sent.
  • ⚠️ Order money is now server-authoritative. shipping_cost and payment_fee sent by the caller are ignored: the delivery cost comes from the store's own rate table for that wilaya and delivery type, and discount is capped at the order subtotal plus shipping. Item prices already worked this way.
  • ✨ GET /v1/shipping/coverage answers whether the linked courier serves a commune and whether it has a stop desk in a wilaya, with the freshness of the courier's own data.
  • ✨ GET /v1/shipping/providers now also reports a courier configured directly on the store rather than added from the provider list, plus is_send_default, economic_available, synced_tier, stock_account, auto_validate and custom_name. Credentials and endpoints are never returned.
  • ✨ GET /v1/landing-pages/{id}/check reports what a buyer would hit on a page: an order form with no product, no order form, more than one, or a section pointing at a product from another store.
  • ⚠️ Publishing a broken landing page is refused. PATCH /v1/landing-pages/{id} with status: active fails with landing_page_has_no_product when the page would take orders at zero. Editing a page that is already live still works, so a broken page can be fixed. A section write naming a product_id from another store is refused as a validation error.
  • ⚠️ PATCH /v1/landing-page-sections/{id} with replace: true now re-seeds the section type's default settings under the object you send, so an omitted key falls back to its default instead of disappearing from the page.
  • ✨ GET /v1/connection lists the stores one connector grant covers and which is active; POST /v1/connection/active-store moves the pointer. The pointer is not a permission: a store the merchant never approved has no key and cannot be selected.

v1.3 — 2026-08-13 (pilot)​

  • ✨ Self-service key management — Enterprise store owners can now generate and revoke API keys from the merchant dashboard at Settings → API (/dashboard/api). Secrets are shown once, at creation.
  • ⚠️ The per-minute rate limit is now enforced per store, shared across all of the store's keys (previously per key). The Enterprise ceiling is unchanged at 600 requests/minute.
  • ⚠️ A store can now hold at most 3 active keys (down from 20), on every mint path — dashboard, POST /v1/keys, and support-issued. Revoking a key frees its slot.

v1.2 — 2026-08-13 (pilot)​

  • ⚠️ The API is now Enterprise-only. Keys authenticate only while their store is on an active Enterprise plan; every other plan — and an expired Enterprise subscription — gets 403 forbidden ("API access requires an active Enterprise plan"). New keys can be minted for Enterprise stores only. Existing keys on non-Enterprise stores stop working immediately but are not deleted: they resume the moment the store moves to (or renews) Enterprise, with nothing to re-issue.
  • ⚠️ The legacy Free / Pro / Unlimited rate-limit tiers are retired. The Enterprise ceiling stays 600 requests/minute per key with no monthly cap; per-store overrides from support still apply.

v1.1 — 2026-08-12 (pilot)​

  • ✨ Product images over the API — POST /v1/products/{id}/images adds an image from a public https URL (DZBuild downloads, optimises and hosts it), PATCH .../images/{image_id} sets alt text / display order / primary, DELETE .../images/{image_id} removes one. Duplicate URLs are de-duplicated, the first image becomes primary automatically, max 20 images per product.
  • ✨ PUT /v1/products/{id}/variants — create and manage variant groups, options and per-combination stock in one call (full replace). Per-option price_adjustment, stock, sku, image_id and show_as_card are now writable, and the stock mode flags are set for you.
  • ✨ GET /v1/products/{id} now returns the combinations block plus the full option fields (price_adjustment, sku, show_as_card, sort_order, is_active) and image alt_text.
  • ⚠️ Breaking-ish: primary_image and images[].url now return full CDN URLs instead of bare filenames. If your code prefixes them manually, remove that logic.

v1.0.1 — 2026-05-02 (pilot)​

  • ✨ POST /v1/orders — create orders via API. Designed for custom themes, headless storefronts, mobile apps, and reseller automation. Server-authoritative line pricing; full variants support; idempotent.
  • 📚 New guide: Custom themes & storefronts — end-to-end build, including catalog rendering, variants UI, cart, checkout, and webhook integration.
  • 📚 New guide: For resellers — manage multiple client stores, bulk operations, white-labeling, billing models.
  • 📚 New guide: Environment & .env setup — safe credential storage across Node, Python, PHP, Go, Vercel, Cloudflare, AWS, Docker/k8s, GitHub Actions.
  • 📚 Expanded Orders reference — full variants documentation including per-variant stock, per-combination stock, cascading variants, image-text variants, multi-piece offers.

v1.0 — 2026-04-30 (pilot)​

  • 🎉 Initial pilot launch.
  • Per-key authentication, rate limiting and read caching.
  • Read endpoints for store / products / orders / customers / landing-pages.
  • Write endpoints with idempotency for products / orders / landing-pages.
  • /v1/signups and /v1/events asynchronous ingest (202 Accepted).
  • Outbound webhooks with automatic retries.