Read your DizLog catalog, stock, customers, sales orders and invoices, and create customers and draft sales orders. Every request is scoped to the business that owns the API key: send the key in x-api-key. Responses are JSON; amounts and quantities are numbers, timestamps are UTC ISO 8601 and IDs are lower-case UUIDs.

Getting started

The DizLog API lets your own software work with a DizLog business. It can read the business's locations, products, stock, customers, sales orders and invoices, and it can create customers and draft sales orders. Webhooks notify your software when that data changes.

Send every request to https://api-payroll.dizlog.com. Each API key belongs to one business, and every request reads and writes that business's data.

1. Open API & Webhooks

You must be an owner or admin of the business.

1. Sign in to DizLog at https://web.dizlog.com.
2. In the sidebar, go to Settings → Integrations → API & Webhooks.

You can also go straight to https://web.dizlog.com/dashboard/business-settings/developers.

2. Create an application

Create one application for each system that connects to DizLog, such as your online shop, ERP or warehouse app. Each application has its own API keys, webhook endpoints, usage history and rate limit.

Select Create application, enter a name, and confirm. You can rename the application later.

3. Create an API key

The Create API key dialog opens as soon as the application is created. To add another key later, open the application and select Create key on the API keys tab.

1. Choose Permissions: Read only (the default), Full access, or Custom to pick resources one by one. Give the key only the access it needs. See Authentication for what each permission allows.
2. Choose when the key Expires: in 30 days, 90 days (the default), 6 months or 1 year, or on a date you pick. A key can last at most one year.
3. Select Create API key and copy the key. It starts with dz_live_.

This is the only time the full key is shown. DizLog keeps only a fingerprint of it, so a lost key can't be recovered. If you lose it, rotate the key to get a new one.

Every key works with the business's real data. While you build, use a Read only key. Add write permissions when you are ready to create records.

4. Make your first request

Keep the key in an environment variable, not in your source code. Send it in the x-api-key header:

export DIZLOG_API_KEY="dz_live_…"

curl "https://api-payroll.dizlog.com/v1/products?limit=50" \
  -H "x-api-key: $DIZLOG_API_KEY"

The response is one page of products:

{
  "data": [
    {
      "id": "3f6c2a4e-8b1d-4c7a-9e2f-5a1b7c9d0e12",
      "name": "Iced Latte 16oz",
      "sku": "BEV-LAT-16",
      "price": 150,
      "currency": "PHP",
      "unitOfMeasure": "Per Item",
      "updatedAt": "2026-09-18T03:12:45.123Z"
    }
  ],
  "limit": 50,
  "nextCursor": null
}

Lists come back one page at a time. If nextCursor is not null, send the same request again with the cursor query parameter set to that value to get the next page. API conventions covers paging, errors and rate limits.

5. Get notified of changes (optional)

You don't have to poll the API for changes. Add a webhook endpoint on the application's Webhooks tab. DizLog then sends a signed request to your server whenever orders, invoices, customers, products or stock change. See Webhooks.

What you can do

The API reference lists every endpoint with its parameters, its responses and the permission it needs.

Create a sales order

A sales order created through the API is a draft. It doesn't take payment or move stock. The merchant reviews its pricing and tax and confirms it in DizLog.

You send quantities, not prices. DizLog prices each line from the product's price at the location and applies any matching price list. The line prices can therefore differ from a product's price, which is its base price.

1. Get the locationId from GET /v1/locations.
2. Get each productId from GET /v1/products. If a product has variants, get the variantId from GET /v1/products/{id}/variants.
3. Get the customerId from GET /v1/customers, or create the customer with POST /v1/customers.
4. Create the order, with a unique Idempotency-Key header for it:

curl -X POST "https://api-payroll.dizlog.com/v1/orders" \
  -H "x-api-key: $DIZLOG_API_KEY" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: shop-order-10023" \
  -d '{
    "customerId": "3f6c2a1e-8b4d-4c1a-9e2f-5a7b8c9d0e1f",
    "locationId": "8b2fc6e6-1c44-44e1-9b72-1e6db59e77b0",
    "currency": "PHP",
    "reference": "SHOP-10023",
    "items": [
      {
        "productId": "3f6c2a4e-8b1d-4c7a-9e2f-5a1b7c9d0e12",
        "variantId": "9b2e4f10-6a3c-4d8e-b1f7-2c5d8e0a4b36",
        "quantity": 2
      }
    ]
  }'

Leave out variantId for a product without variants. If the request times out, send it again with the same Idempotency-Key. DizLog then returns the first order instead of creating a second one.

The request fails with PRODUCT_PRICE_NOT_AVAILABLE if an item has no price at that location in that currency. The error's details list names each failing item.

Authentication

Send your API key in the x-api-key header of every request:

curl "https://api-payroll.dizlog.com/v1/locations" \
  -H "x-api-key: $DIZLOG_API_KEY"

A key is dz_live_ followed by 64 hexadecimal characters. Each key belongs to one application of one business. Owners and admins manage keys in DizLog under Settings → Integrations → API & Webhooks, using their normal DizLog login.

The key decides the business

Every request works with the data of the business that owns the key. You can't choose another business. A request that sends businessId or business in the query or body, or an x-business-id header, fails with 403 TENANT_OVERRIDE_NOT_ALLOWED.

An ID that belongs to another business behaves as if it doesn't exist. In the path it returns NOT_FOUND. In the query or body it returns LOCATION_NOT_FOUND or CUSTOMER_NOT_FOUND, or PRODUCT_PRICE_NOT_AVAILABLE for an order item's productId or variantId.

Permissions

Each endpoint needs one permission, called a scope. When you create a key, choose Read only, Full access or Custom:

Custom lets you pick scopes one by one. A write scope doesn't include reading, so tick both if your integration also needs to look records up. Give each key only the scopes it needs.

A key without the scope an endpoint needs gets 403 INSUFFICIENT_SCOPE, and the error message names the missing scope. You can't edit a key's scopes. Rotate the key and choose the new scopes.

Manage keys

Open the application's API keys tab. Each application can have up to 10 active keys, and each key shows when it was last used.

• Expiry: every key expires, at most one year after it is created. Rotate it before then.
• Rotate: creates a new key with the scopes and expiry you choose. The old key stops working at once, so have the new key ready to deploy.
• Swap keys with no downtime: create a second key, switch your integration to it, then revoke the first key.
• Revoke: the key stops working at once. You can't undo this.
• Disable the application: on the application's Settings tab. All its keys stop working and its webhook endpoints stop receiving events. Nothing is deleted. When you enable it again, keys that haven't expired or been revoked work again.

The Activity section of the Settings tab lists the changes made to the application, its keys and its endpoints in the last 90 days.

Keep keys secret

• Keep keys on your server or in a secrets manager.
• Never put a key in browser code, a mobile app, a URL, logs, analytics, source control, screenshots or support tickets.
• If a key might have leaked, revoke it, or rotate it, straight away.

When a request is rejected

DizLog checks the key before it checks anything else about the request. A request with a bad key therefore gets 401 even if its body is also invalid. The one exception is the body itself: a body that isn't valid JSON, is larger than 1 MB, or isn't UTF-8 is rejected before the key is checked.

API conventions

These rules apply to every endpoint.

Requests

• The base URL is https://api-payroll.dizlog.com, and every endpoint starts with /v1.
• Send the API key in the x-api-key header.
• Send request bodies as UTF-8 JSON with Content-Type: application/json. A body can be at most 1 MB.
• Unknown body fields and query parameters are rejected with INVALID_REQUEST, not ignored.
• An optional field sent as null or as blank text counts as left out.
• IDs are UUIDs. Upper and lower case are both accepted.

Responses

A single record comes back as { "data": { … } }. A list comes back as { "data": [ … ], "limit": 50, "nextCursor": "…" }.

• Fields: every documented field is always present. A missing value is null, never a missing key. New fields can be added within v1, so ignore fields you don't know.
• IDs: lower-case UUID strings, including IDs you sent, such as the inventory locationId.
• Amounts and quantities: JSON numbers, rounded to the precision DizLog stores. Prices and sales-order amounts have up to 4 decimals, invoice amounts 2, and quantities and stock 6. Parse amounts into a decimal type before doing arithmetic with them.
• Timestamps: ISO 8601 in UTC with a Z suffix, such as 2026-09-18T03:12:45.123Z. This includes an invoice's dueDate.
• Text: trimmed. Blank optional text, such as a SKU, address line, email, phone, order number or reference, is null. On older records, a customer name can be an empty string and a product name can be null.
• Currencies: upper-case ISO 4217 codes, as the merchant set them up.
• Statuses: a sales order is DRAFT, CONFIRMED, INVOICED or CANCELLED. An invoice is currently DRAFT, PENDING_APPROVAL, APPROVED, SENT, PAYMENT_PENDING, PARTIALLY_PAID, PAID, CANCELLED or VOID. More values can be added, so handle an unknown status without failing.
• Order lines: listing sales orders returns them without their lines. Getting or creating one order returns it with its items.
• Stock: quantities can be negative when a merchant sells below zero. available is onHand minus reserved. Rows with stockTracked set to false are products that don't track stock, such as services. Their quantities are 0 and mean nothing.
• Older records: a few hold a stored amount that isn't a number. Lists leave out such products and sales orders, and getting one returns NOT_FOUND. Such a variant price is null.

Pagination

Lists return one page at a time.

• limit sets the page size, from 1 to 100. The default is 50.
• To get the next page, send the same request, with the same endpoint and filters, and set cursor to the previous page's nextCursor.
• On the last page, nextCursor is null.
• Treat a cursor as an opaque value, and don't build or edit one. A cursor that is malformed, or that came from another endpoint or other filters, returns 400 INVALID_CURSOR. Start again from the first page.
• Lists are ordered by ID. A record created while you page shows up on a later page or not at all, and no record repeats.
• An inventory page can hold fewer rows than limit and still have a nextCursor when products change while you page.
• Lists don't return a total count.

Rate limits

Each application can make 120 requests per minute. Every key of the application shares this limit. Each minute is a fixed UTC minute, and the count resets when the next one starts.

Responses carry X-RateLimit-Limit and X-RateLimit-Remaining. Once the limit is used up, requests get 429 RATE_LIMIT_EXCEEDED with a Retry-After header. Wait that many seconds, add a little random delay, and try again.

Idempotency

Creating a customer or a draft sales order requires an Idempotency-Key header. The value is 8–128 ASCII letters, digits, dots, colons, underscores or hyphens. Use a new value for each thing you create, and reuse it when you retry that same request. Your own ID for the record works well, such as shop-order-10023.

• Same key, same body: DizLog returns the original record with 201 instead of creating another one. A replayed order is returned as it is now.
• Same key, sent at the same time: the requests wait for the first one to finish and return the same record.
• Same key, different body: 409 IDEMPOTENCY_CONFLICT. Keys are separate for each application and for each kind of record.
• After a timeout, a network error, a 5xx or a 429: retry with the same key and the same body. Never retry an uncertain create with a new key, or you may create the record twice.
• After any other 4xx, such as INVALID_REQUEST or PRODUCT_PRICE_NOT_AVAILABLE: fix the request, then send it with a new key.
• NOT_FOUND on a retry: the record the first request created has since been deleted or removed from the business.

Errors

Every error has the same shape:

{
  "error": {
    "code": "INVALID_REQUEST",
    "message": "The request is invalid. See details for each problem.",
    "requestId": "5f0c9a8e-2b1d-4c3e-9f7a-6b5c4d3e2f10",
    "details": [
      { "field": "items[0].quantity", "message": "must not be less than 0.000001" }
    ]
  }
}

• code: branch on this, not on message or the HTTP status. Messages are for people and their wording can change. New codes can be added within v1, so handle an unknown code by its HTTP status.
• details: only on INVALID_REQUEST and PRODUCT_PRICE_NOT_AVAILABLE, with one entry per problem when DizLog can tell which input failed. It can be missing, for example when an item stops being sellable while the order is being created. field is a path such as limit, id or items[0].quantity. Messages never repeat the values you sent.
• requestId: quote it when you contact support. Never send support your API key or customer data.

FORBIDDEN (403) and CONFLICT (409) are general codes for a status that has no more specific code. The reference lists the codes each endpoint can return, with an example of each.

A request gets the first error that applies, in this order:

1. API key present
2. API available
3. Key valid
4. No business override
5. Rate limit
6. Scope
7. Request validation
8. Idempotency-Key
9. Business rules, such as NOT_FOUND or PRODUCT_PRICE_NOT_AVAILABLE

Some requests fail before any of these checks: a body that isn't valid JSON, is too large or isn't UTF-8, and a path that matches no endpoint.

Headers

• Every response has X-Request-Id. On an error it equals error.requestId.
• Every response has Cache-Control: no-store.
• X-RateLimit-Limit and X-RateLimit-Remaining appear once the rate limit has been checked. They are missing on 401, on a business override, while the API is unavailable, and on body errors that are rejected before any check.
• 429 and 503 responses carry Retry-After in seconds.

Data and privacy

• Customer records expose only the customer's ID, name, email, phone and update time.
• Reading invoices and customers each needs its own scope.
• Payroll, salaries, attendance, payment credentials and internal records aren't part of this API.
• DizLog counts requests per application for each UTC day. Owners and admins see these counts on the application's Usage tab.

Versioning

The reference is generated from the API code and checked against it on every change. Changes within v1 only add things: new endpoints, new response fields, new error codes and new invoice statuses. Build your client to accept them. Breaking changes go into a new API version.

Webhooks

Webhooks tell your server when data changes, so it doesn't have to poll the API. When something changes, DizLog sends a signed HTTPS POST to every endpoint that subscribes to that event. The event carries only IDs. Fetch the record from the API to get its current data.

Set up an endpoint

1. In Settings → Integrations → API & Webhooks, open the application and go to the Webhooks tab.
2. Select Add endpoint.
3. Enter the Endpoint URL and pick the Events to receive.
4. Select Add endpoint. DizLog sends a webhook.test event right away, and the dialog shows how your server answered.
5. Copy the Signing secret and store it on your server. You need it to check that each request comes from DizLog. You can reveal it again on the endpoint's page. It is not an API key.

Each application can have up to 5 enabled endpoints, and one endpoint can subscribe to any number of events.

The endpoint URL must:

• use HTTPS on the standard port, 443
• use a public hostname, not an IP address, localhost, or a special-use name such as .test, .example, .invalid, .local or .internal
• resolve to public IPv4 addresses. Hosts that have only IPv6 addresses, or that resolve to private, loopback, link-local or reserved addresses, get no deliveries. DizLog checks the address on every delivery.
• not contain a username, password or # fragment

Events

Events are created only for endpoints that are enabled, in applications that are enabled. Changes made while an endpoint is disabled are never sent to it.

Details

• product.updated: other product changes send nothing, including a change to updatedAt alone.

• inventory.updated: sent when:

  • a product is added to a location
  • its on-hand stock, status or deletion at a location changes
  • the stock reserved at a location changes

  A fulfillment reserves its lines' stock at its warehouse while it is released, picking, picked or packed. An event is sent when a line is added or removed, or when a line's allocated or shipped quantity changes. One is also sent when a fulfillment enters or leaves those statuses, for example when it ships or is cancelled. Moving between released, picking, picked and packed doesn't change what is reserved, so it sends nothing. Moving a fulfillment that holds stock to another warehouse sends an event for both warehouses. variantId is null for a product without variants.

• customer.updated: each business the customer belongs to gets its own event.

• order.updated: sent when an order is saved, even if only its updatedAt changes. Creating a fulfillment for the order also sends it, and so does changing a fulfillment's status or warehouse. Editing only an order's items, without changing its totals, sends nothing.

• invoice.paid: sent when an invoice's status becomes PAID, including an invoice created already paid, such as a paid online-store order.

  • It is sent once each time the invoice becomes paid. If a payment is reversed and made again, you get the event again.
  • A balance that reaches zero without a payment, for example after a full return, is not a payment.
  • A post-dated cheque counts when it is recorded. If it bounces, the invoice reopens without an event.

These changes send no event:

• invoice changes other than becoming paid
• changes to a product variant's SKU or price
• lot and expiry changes to on-hand stock
• changes to whether a product tracks stock
• stock released when a whole fulfillment or order item is deleted

What DizLog sends

Each delivery is a POST with a JSON body:

{
  "id": "0c2f7d3e-5b1a-4e8f-9d6c-3a2b1c0d9e8f",
  "type": "order.updated",
  "createdAt": "2026-09-18T03:12:45.123Z",
  "data": { "id": "9b2f1c4e-0b45-44e3-9a76-1f2c3d4e5f60" }
}

For inventory.updated, data names the stock row:

{
  "productId": "3f6c2a4e-8b1d-4c7a-9e2f-5a1b7c9d0e12",
  "variantId": null,
  "locationId": "8b2fc6e6-1c44-44e1-9b72-1e6db59e77b0"
}

The request has these headers:

Verify the signature

Check the signature before you trust or process a request:

1. Read t and v1 from the DizLog-Signature header.
2. Compute HMAC-SHA256 over t, a dot, and the raw request body, exactly as received. Use the signing secret text as the key, as it is: don't decode it from hex.
3. Compare the result with v1 using a constant-time comparison.
4. Reject the request if t is more than five minutes away from your server's clock.

In Node.js:

import { createHmac, timingSafeEqual } from 'node:crypto';

export function verifyWebhook(secret, header, rawBody) {
  const match = /^t=(\d+),v1=([a-f0-9]{64})$/.exec(header || '');
  if (!match || Math.abs(Date.now() / 1000 - Number(match[1])) > 300) return false;
  const expected = createHmac('sha256', secret)
    .update(match[1] + '.').update(rawBody).digest();
  return timingSafeEqual(expected, Buffer.from(match[2], 'hex'));
}

With Express, read the raw body for the webhook route, so it hasn't been parsed and re-serialized:

import express from 'express';

const app = express();

app.post('/webhooks/dizlog', express.raw({ type: 'application/json' }), (req, res) => {
  const secret = process.env.DIZLOG_WEBHOOK_SECRET;
  if (!verifyWebhook(secret, req.get('DizLog-Signature'), req.body))
    return res.sendStatus(400);
  const event = JSON.parse(req.body.toString('utf8'));
  // Save the event, answer, then process it in the background.
  res.sendStatus(200);
});

Answer within 8 seconds

Answer with any 2xx status within 8 seconds. Save the event first, answer, and then do the work in the background. Everything else counts as a failed attempt:

• a 3xx, 4xx or 5xx status (DizLog doesn't follow redirects)
• no answer within 8 seconds
• a refused connection
• a response body larger than 64 KB

Retries

DizLog sends an event shortly after the change is saved, usually within 15 seconds. If the attempt fails, it tries again after 30 seconds, and then after 1, 2, 4 and 8 minutes. That makes 6 attempts over about 15 minutes. After the last failed attempt, the delivery is marked Failed.

Every attempt carries the same event ID and body, with a new signature timestamp.

Duplicates and order

Delivery is at least once, and events can arrive out of order.

• Deduplicate by the event ID, from DizLog-Event-Id or the body's id. The same event can arrive again after a retry or a replay, or when your server saved it but its answer didn't reach DizLog.
• Don't rely on the order of events. When an event arrives, fetch the record from the API and use its current state.

Monitor deliveries

The endpoint's page lists its deliveries from the last 7 days, newest first. You can filter them by status and by event. Open a delivery to see its payload, its attempts and your server's last answer.

• Send test event sends a webhook.test event, at most once a minute.
• Replay sends a failed delivery again with the same event ID and a new round of attempts. It works on deliveries from the last 7 days, while the endpoint and application are enabled.
• Retry now skips the wait before a waiting delivery's next attempt.

A replay or retry goes out within 15 seconds.

Deliveries are deleted after 7 days.

Manage endpoints

• Edit changes the URL or the events. The signing secret stays the same.
• Disable endpoint stops deliveries right away. Deliveries already waiting are paused, and they resume if you enable the endpoint within 7 days. Disabling the application pauses all of its endpoints in the same way.
• Reveal shows the current signing secret.
• Roll signing secret replaces the secret. DizLog signs with the new secret straight away, and your server rejects requests until it has the new one. Rejected deliveries keep retrying for about 15 minutes. After that, replay any that failed.