Dikafy
ENVI
FeaturesPricingAboutContactDevelopersGuide
Create your store

Developers

Developer API

Connect a Dikafy store to whatever else you run — an ERP, a 3PL, a warehouse, a spreadsheet, a script you wrote on a Tuesday.

Open the API referenceDownload the OpenAPI description

Start in three steps

  1. 01

    Create a key

    In your dashboard, go to Settings → API keys and create one. It is shown once, at creation — Dikafy stores only a hash of it, so a lost key is replaced rather than recovered.

  2. 02

    Give it only what it needs

    Grant a key full access for its role, or narrow it to the resources it actually touches. A warehouse integration usually wants orders and fulfillments, and nothing else.

  3. 03

    Call the API

    Send the key as a bearer token. It names its own store, so there is no store id to pass and no way to reach a store the key was not made for.

A first request

curl https://YOUR-STORE.dikafy.com/api/v1/store/products \
  -H "Authorization: Bearer dk_sk_YOUR_KEY"
{
  "status": true,
  "products": [
    { "id": 42, "title": "Makeup bag", "handle": "makeup-bag", "status": "active" }
  ],
  "total": 1
}

Every response is the same envelope: a boolean status, and at most one named payload. A page of rows also carries a total.

Scopes and roles

Two gates apply to every call, and it has to pass both. The scope says which resources a key may touch and whether it may write; the role is the store role the key was given, capped by the role of whoever created it. The reference marks both on every endpoint.

What a key can never do

Some endpoints are refused to every key, whatever its scope or role: inviting or removing staff, closing the store, changing payment gateways or the billing card, and managing API keys. Those decide who and what can act on the store, and two of them would outlive revoking the key that used them.

Webhooks

Rather than polling, subscribe to events. Dikafy posts them to your endpoint signed with HMAC-SHA256 in an X-DK-Signature header, and retries with backoff when your endpoint is down.

Available topics

order.paid
A payment is captured and the order exists.
order.refunded
A refund succeeds, in full or in part.
order.fulfilled
A shipment is created against an order.
order.cancelled
An order is cancelled.
upsell.accepted
A shopper accepts a post-purchase offer.
checkout.abandoned
A checkout is flagged as abandoned.
cart.abandoned
A cart is flagged as abandoned.
checkout.recovered
An abandoned checkout converts.

Rate limits

Requests are limited per key, per minute. Every response carries the limit and what is left of it; a 429 tells you how long to wait. Read the headers rather than guessing — the limit is set per deployment.

When something goes wrong

A failure is the same envelope with status false and a message written for a person. The status code says what kind of problem it is.

400
The request could not be read, or a value was not valid.
401
No key, or one that is unknown, revoked or expired.
403
The key lacks the scope or role — or the endpoint is closed to keys entirely.
404
No such record in this store.
409
The request conflicts with what is already there.
429
Too many requests. Wait for Retry-After.