Developer access & API keys

Choose an integration identity

Open Settings - Developer access as an owner or administrator. A service account represents an integration, not a teammate: it cannot sign in to the application and does not consume a user seat. Choose a recognizable name and explicit current object permissions. Each object needs Read; Create, Update, Delete and Add notes can be added where supported. Read includes every field and owner for that object. Fine field/team/owner policies are not implied. Financial objects allow only Read and Add notes through this API.

Approve an expiring key

Approve creating an account, expanding access, enabling a disabled account, issuing a key or rotating one with your current password. Access approval is limited to 30 attempts per account per 15 minutes. Each key has its own permissions within the saved account ceiling and expires after 1-365 days. Accounts support up to ten active keys; workspaces support up to100 active service accounts. New objects receive no automatic permission.

A newly issued secret appears once. Keep it in your integration’s secret store, never in a website, browser bundle, URL, shared screenshot or source repository. List/detail/history responses contain only metadata and a public prefix. If the first response is lost, retrying the same reference returns the existing key with no secret; revoke that key and issue a replacement.

Narrow, disable, rotate or revoke

Reducing account permissions permanently narrows existing keys. A later expansion does not silently restore them. Disabling the account blocks all its keys; enabling again requires password approval. Rotate issues a replacement and immediately revokes the old key; update the integration to use the one-time replacement. For a staged change, issue a separate key first and revoke the old one afterward.

Revocation and disablement wait for business transactions already using the key. Those can finish; future requests fail. Revoked keys and disabled accounts remain in history. API request history lists normalized operations/statuses and public integration names, with pagination and no customer payloads or credentials. Final history is asynchronous and can omit a row if the process exits before recording it; valid authenticated attempts are durably metered before dispatch.

Use the versioned CRM API

Use Authorization: Bearer with the secret under https://app.drykraft.com/api/v1. Browser session cookies cannot replace a key here; keys cannot access browser, billing, workflow, provider or administrator endpoints. /me reports the current effective permissions; /objects shows authorized schemas. Contacts, companies, leads, opportunities and tasks have native collection aliases; /records/{key} also supports custom objects and financial reads.

Writes require a UUID Idempotency-Key, current permission and active trial/paid access. PATCH keeps omitted fields and requires the current record version. The same key/account/request reference retries without repeated records, notes or events. Reusing it with another path or payload conflicts. Preserve field order when retrying; the validated serialized JSON must match. Refresh after409. Archived contact references remain resolvable. Financial writes and deletion use Finance in the application. Signed customer webhooks, an external SDK and service-account workflow/provider administration remain outstanding.