Skip to main content

DZBuild API — Introduction

Build on DZBuild — full REST API for stores, products, orders, customers, landing pages, signups, and webhooks.

Written by Support

The DZBuild API lets you manage your store programmatically: products, orders, customers, landing pages, plus a high-volume signup tracker for merchants embedding DZBuild in their own platforms.

Base URL: https://api.dzbuild.app/v1 — the only supported public base URL. Versioning: stable v1. Breaking changes require a new path prefix. Format: JSON in, JSON out, UTF-8. Authentication: see Authentication. Availability: Enterprise plan only. API keys can only be issued for stores on an active Enterprise plan, and any call from a store that is not currently on Enterprise returns 403 forbidden. Status: Pilot. To enroll, contact [email protected] with your store id and we will issue you a key. A valid key that is not pilot-enrolled gets 403 forbidden on every call.

⚠️ Warning — Point your integration at api.dzbuild.app, nothing else

https://dzbuild.com/api/v1 is an internal alias, not an integration target. On that hostname: /v1/signups and /v1/events do not exist (404), public-key (DZ-Public) calls are rejected with 401, and there is no idempotent replay, no per-key rate limiting and no read cache.

Quickstart

curl https://api.dzbuild.app/v1/ping

Response:

{ "data": { "pong": true, "time": "2026-04-30T20:15:59.836Z", "edge": true },
  "meta": { "request_id": "...", "api_version": "v1", "edge": true } }

Authenticated request:

curl https://api.dzbuild.app/v1/whoami \
  -H "Authorization: Bearer <your_key_id>.<your_key_secret>"

Envelope

Every response follows the same shape:

Success

{ "data": ..., "meta": { "request_id": "...", "api_version": "v1" } }

Error

{ "error": { "code": "rate_limited", "message": "...", "retry_after": 12 },
  "meta": { "request_id": "...", "api_version": "v1" } }

Response headers

Header

When

Meaning

X-Request-Id

Every response

Same value as meta.request_id. Send your own X-Request-Id and we echo it back, so your logs and ours line up.

X-Api-Version

Most responses

Always v1. Not present on idempotent replays or read-cache hits.

X-Cache

Cacheable GETs

HIT served from the read cache, MISS served fresh.

Idempotency-Replay

Replayed writes

1 means this is the stored response of an earlier call with the same Idempotency-Key — no new side effect happened. See Idempotency.

Good to know

  • Your key is verified on every single request — Bearer tokens and public-key HMAC signatures alike.

  • The per-minute rate limit applies per store — all of a store's keys share one budget — on a fixed 60-second window (the counter resets on each wall-clock minute). Enforcement is approximate under bursts, so handle 429 defensively rather than pacing exactly to the limit. It applies to API calls only — a merchant's storefront, checkout and dashboard never consume it. See Rate limits.

  • A short read cache (30 s, scoped per API key) covers GET /v1/store, GET /v1/products (collection) and GET /v1/landing-pages (collection). Every other GET is always served fresh. The query string is part of the cache key, so ?status=active and ?status=draft cache separately.

  • High-volume writes (/v1/signups, /v1/events) are accepted asynchronously and return 202 Accepted immediately — your call doesn't wait for processing to finish.

Related Articles
Did this answer your question?