Authorization

Create an API key, send it with every request, and understand why some keys are rejected.

Every request is authenticated with an API key, and that is the only credential you need to send.

Create an API Key

Open the dashboard

Go to Dashboard → Config → API Keys.

Create the key

Click Create API Key and give it a name that identifies the system using it, such as Billing Service.

Copy it now

Keys look like this, and this is the only time you will see the whole thing:

key_Wb22OsfMPpEkAHeS6LHqBWoaFkpEuCdyZx3pt5RvICo

The full key is shown once, at creation. After that only a masked form (key_A1b2C3d4…xY9z) is visible. If you lose it, revoke the key and create a new one.

Send the key

Three header forms are accepted, so you can reuse whichever convention your HTTP client already has:

Authorization: Bearer key_xxx
Authorization: key key_xxx
Authorization: key_xxx

cURL

curl --location 'https://api.nextsign.dk/v3/api/cases' \
  -H "Authorization: Bearer ${NEXTSIGN_API_KEY}" \
  -H 'Content-Type: application/json' \
  --data-raw '{ "title": "Test", "state": "draft" }'

A key belongs to exactly one company, and everything you create with it belongs to that company. Use a separate key per system, so you can revoke one without disturbing the others.

Who your cases belong to

Every case is attributed to a person, and that decides two real things: which colleagues can see it — through the folder's role list — and who the signing email says it came from.

By default that person is whoever created the key, and the response says so with a sender-defaulted-to-key-creator notice. To attribute a case to a specific colleague instead, send senderId or senderEmail — see Sender. That user must be a member of the same company.

If one key serves a whole team, name the sender on every request. Otherwise every case is owned by — and appears to come from — the colleague who happened to create the key.

Authentication errors

All of these are returned before your request body is looked at.

Status	`error`	Meaning
`401`	`missing-token`	No `Authorization` header
`401`	`invalid-token`	The key does not exist
`401`	`key-revoked`	The key was revoked in the dashboard
`401`	`key-expired`	The key passed its expiry date
`403`	`company-disabled`	The company account is disabled

401 Unauthorized

{
  "error": "invalid-token"
}

key-revoked and key-expired are deliberately distinguished from invalid-token. You already hold the key, so this reveals nothing — and it saves you debugging an integration that was simply turned off or aged out.

Storing keys

.env

NEXTSIGN_API_KEY=key_your_key_here
NEXTSIGN_V3_URL=https://api.nextsign.dk/v3/api

Keys are stored hashed on our side and cannot be recovered — not by you, and not by support. Treat one as you would a database password: keep it out of source control, out of client-side code, and out of logs.

Revoking a key in the dashboard takes effect immediately on the next request.