Authentication

Every request to /api/v1 is made with a workspace API key. A key belongs to the workspace, not to the person who made it, so it keeps working when they leave, and the workspace’s audit log names the key as the one that acted.

Making a key

An owner or admin makes keys in Settings › API keys:

1. Name it (up to 48 characters), for whoever will use it: “Warehouse sync”, “Zapier”.
2. Give it access module by module: none, read, or read and write. Write always includes read.
3. Choose when it expires: in 30, 90 or 365 days, or never.

The key is shown once, starting with dgz_live_. Digize keeps only a hash of it; the page lists each key’s first characters, what it can reach, who made it, when it was last used and when it expires. Deleting a key there refuses its requests from then on.

Keys can’t be made or deleted through the API, and members can’t be invited or changed through it (it can list them): those take a signed-in person.

Sending it

In either header:

curl https://digize.com/api/v1/sites -H "x-api-key: dgz_live_…"
curl https://digize.com/api/v1/sites -H "authorization: Bearer dgz_live_…"

Keep keys on servers. A key in a browser, an app or a site’s static files is a key anyone can copy; a site’s Worker keeps one in a secret.

Permissions

A key’s access is a set of permissions, one per module and level:

Module	What it covers
crm	Contacts, companies, opportunities and pipelines, conversations and messages, calendars and appointments, invoices, payments, payment links and subscriptions, mailings and lead lists, tags, templates and custom fields
sites	Workers and deployments, domains and DNS, D1, R2, KV and queues, bindings, email sending and routing
commerce	Products, collections, stock and locations, discounts, gift cards, customers, checkouts, orders and store settings
automations	Workflows, their runs and credentials, Google Sheets, and Zapier’s REST hooks
ads	Ad accounts, campaigns, ads, audiences, the creative library, click protection and short links
analytics	Reports, funnels, goals, analytics settings and Search Console’s data
reviews	Reviews and replies, review requests, the Business Profile with its posts and photos, NFC cards and taps, and private feedback
settings	The workspace’s own settings: general, branding, modules, members, integrations, billing, the audit log and webhook endpoints

Each operation needs one permission, such as crm:read for GET /api/v1/contacts or crm:write for POST /api/v1/contacts. The reference shows it on every operation, and the OpenAPI document has it as x-permission. A few operations need more, because of what they hand out: subscribing a webhook to crm.* events also needs crm:read (Webhooks).

When a key is refused

Status	code	When
401	unauthorized	No key, or one that’s unknown, deleted or expired. The answer has www-authenticate: Bearer.
403	forbidden	The key doesn’t have the operation’s permission: This key needs the crm:write permission.
403	forbidden	The workspace is read-only for an unpaid bill, and the request writes something other than settings. details.reason is billing_read_only; reads still work, and settings stay writable so the card can be fixed.
429	rate_limited	20 keys that don’t work from one address in a minute: that address waits out the minute (Rate limits).

Note

Permissions are checked before anything is read from your request’s body, so a key that can’t make a change learns nothing about the data it would have changed.