For resellers

If you build storefronts for clients — agencies, freelancers, fulfillment companies, marketplace operators — the DZBuild API is designed to be your operational backbone.

This guide is for you if any of these apply:

You manage 5+ DZBuild stores for different clients.
You bill clients per-order or per-month and need a reliable usage signal.
You build custom themes or custom storefronts on behalf of clients.
You sell DZBuild as a white-label layer ("MyAgency Commerce, powered by DZBuild").
You want to script bulk operations: bulk-import products, bulk-update prices, bulk-confirm orders.

How resellers actually use the API

A typical reseller setup:

                                ┌─────────────────────────┐
                                │  Your back-office /     │
                                │  agency dashboard       │
                                │  (your code, your UI)   │
                                └──────────┬──────────────┘
                                           │  Bearer dzpk_live_…
                                           ▼
                            ┌─────────────────────────────┐
                            │  api.dzbuild.app/v1/*       │
                            └──────────┬──────────────────┘
                                       ▼
                           ┌──────────┬─────────┬──────────┐
                           │ Store A  │ Store B │ Store C  │   ← clients you manage
                           └──────────┴─────────┴──────────┘

Each client has their own DZBuild store (their merchant account, their plan, their orders). You hold an API key per store and orchestrate everything — onboarding, customizing, ordering reports — from your own dashboard.

Key model for resellers

There's no special "reseller key" type. Every reseller works with one platform key per client store. You either:

A) Each client mints the key and shares it with you (recommended for arms-length client relationships)

The client logs into their own DZBuild dashboard, mints a key, and gives you the secret. You store all client secrets in your reseller back-office, encrypted. Each operation you run against client X uses client X's key.

Pros: clear consent, client owns the key, can revoke any time. Cons: onboarding friction (client has to do a setup step).

B) You hold a master Algerian-business agreement with DZBuild, and we mint keys for you

For agencies managing 20+ stores, contact us. We can issue a single "agency umbrella" config that lets you mint keys programmatically as you onboard new clients. (This is a Pro+ / Enterprise feature.)

Pros: zero-friction client onboarding. Cons: requires a written agreement; you're operationally responsible for any abuse on those keys.

Bulk product imports

Building a catalog for a client? Use a CSV → API loop:

import requests, csv, uuid, os

KEY = os.environ['DZ_KEY_CLIENT_X']
HEADERS = {
    'Authorization': f'Bearer {KEY}',
    'Content-Type':  'application/json',
}

with open('products.csv') as f:
    for row in csv.DictReader(f):
        body = {
            'name':           row['name'],
            'price':          float(row['price']),
            'compare_price':  float(row['compare_price']) if row['compare_price'] else None,
            'sku':            row['sku'],
            'description':    row['description'],
            'stock_quantity': int(row['stock']),
            'track_stock':    True,
            'status':         'active',
        }
        r = requests.post(
            'https://api.dzbuild.app/v1/products',
            headers={**HEADERS, 'Idempotency-Key': str(uuid.uuid4())},
            json=body,
        )
        if r.status_code == 201:
            print(f"OK {row['sku']} → id {r.json()['data']['id']}")
        else:
            print(f"FAIL {row['sku']}: {r.text}")

Tips:

Use a deterministic idempotency key (e.g. import-{client}-{sku}-{run}) so retries skip already-imported rows.
The pro_plus rate limit is 5000 req/min — plenty for ~1000 product imports in 30 seconds.
Image uploads go through the dashboard for now; the API will support presigned R2 PUT in v1.1.

Bulk order operations

Confirm all pending orders for one client

KEY="$(cat /etc/secrets/client-x.key)"
# 1. List pending
curl -sS 'https://api.dzbuild.app/v1/orders?status=pending&limit=200' \
  -H "Authorization: Bearer $KEY" \
| jq -r '.data.items[].id' \
| while read OID; do
    # 2. Confirm each
    curl -sS -X PATCH "https://api.dzbuild.app/v1/orders/$OID" \
      -H "Authorization: Bearer $KEY" \
      -H "Content-Type: application/json" \
      -H "Idempotency-Key: confirm-$OID" \
      -d '{"status":"confirmed"}'
  done

Daily revenue report across all clients

clients = json.load(open('clients.json'))  # [{name, key}, ...]
today = date.today().isoformat() + 'T00:00:00Z'

for c in clients:
    orders = requests.get(
        f'https://api.dzbuild.app/v1/orders?since={today}&limit=200',
        headers={'Authorization': f'Bearer {c["key"]}'},
    ).json()['data']['items']
    revenue = sum(o['total'] for o in orders if o['status'] == 'delivered')
    print(f"{c['name']}: {len(orders)} orders, {revenue} DZD")

White-labeling

You want your storefronts to feel like your brand, not DZBuild's. The API enables that:

Build the front-end yourself with whatever stack/branding you want (see Custom themes & storefronts).
Use your own domain (shop.yourbrand.com) — point it at your custom storefront, your storefront talks to DZBuild via API.
The merchant dashboard at dzbuild.com/dashboard stays DZBuild-branded — that's where you (or your client) confirm orders. Your end customers never see DZBuild branding.

For end-to-end white-label including a custom merchant dashboard, see Enterprise plans.

Webhooks for resellers

curl -X POST 'https://api.dzbuild.app/v1/webhooks' \
  -H "Authorization: Bearer $CLIENT_X_KEY" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: $(uuidgen)" \
  -d '{
    "url":    "https://api.youragency.com/dz-hooks?store=client-x",
    "events": ["order.created","order.confirmed","order.shipped","order.delivered","order.cancelled"]
  }'

Use the ?store=client-x query parameter so a single endpoint can handle all clients. Verify the signature with the per-client secret to ensure it's really DZBuild calling.

Multi-store accounts

Some clients run multiple stores in one DZBuild account (the Multi-store feature). Each store gets its own API key — they're independent. Keep them clearly named in your secrets manager:

DZ_KEY_CLIENT_X_BRAND_A=dzpk_live_...
DZ_KEY_CLIENT_X_BRAND_B=dzpk_live_...

Client size	Recommended plan	Why
0–30 orders/month	Free	Validate the idea before committing
30–500 orders/month	Pro	Removes order limits + opens API access (`pro` tier)
500–2000 orders/month	Pro+	API rate limit jumps to 5000 req/min — needed for bulk syncs
2000+ / multi-brand	Enterprise	Unlimited rate limit, custom contract, priority support

The API itself is included on Pro and up. Free-plan stores cannot mint API keys.

Billing your own clients

The API gives you accurate usage signals so you can bill confidently:

GET /v1/usage — current month's API call count, broken down by endpoint group
GET /v1/usage/history — last 12 months
GET /v1/orders?status=delivered&since=... — for per-order commission models

Most resellers charge clients:

A flat monthly fee for storefront hosting + DZBuild license re-sale
A % commission on delivered orders (read from ?status=delivered)
Or a bundled subscription (e.g. "10000 DZD/month for everything")

Pick whichever model your market expects.

Operational tips

One environment per client. Dev secrets in dev. Prod secrets in prod. Never share keys across.
Use deterministic Idempotency-Keys for any retry loop (especially bulk imports / bulk confirms).
Cache product reads. The edge already caches reads for 30 s but you can layer your own 5-min cache on top — products rarely change minute-to-minute.
Rate-limit yourself. Don't spike to 5000 req/min the moment you can — leave headroom for the merchant's organic traffic.
Set up Telegram alerts on your end for 429 rate_limited, 5xx, or webhook delivery failures.
Quarterly audit: rotate keys for stores you no longer manage. Use DELETE /v1/keys/{key_id}.

Reference

Authentication — Bearer + DZ-Public flows
Idempotency — required on all writes
Rate limits — per-tier caps
Webhooks — push instead of poll
Custom themes & storefronts — full headless build

How resellers actually use the API​

Key model for resellers​

A) Each client mints the key and shares it with you (recommended for arms-length client relationships)​

B) You hold a master Algerian-business agreement with DZBuild, and we mint keys for you​

Bulk product imports​

Bulk order operations​

Confirm all pending orders for one client​

Daily revenue report across all clients​

White-labeling​

Webhooks for resellers​

Multi-store accounts​

Plan tiers — what to recommend​

Billing your own clients​

Operational tips​

Reference​