Book a demo
Pricing

API keys. Managed in admin.

Create keys, set permissions per resource, restrict to IP addresses, rotate with an overlap and revoke on the spot. No support ticket, no shared password in a chat thread.

Book a technical demo An API for keys

Every key, every environment.

The admin overview

A key is never shown in clear text after creation — only the prefix, so a key in a log can be identified without being exposed.

Create a key

Permissions per resource, not all or nothing.

Shown once hdl_live_7Kq2vR9pLm4XbTn8sWzQ1cYhE6… Copy

The secret is shown once the key is created and stored hashed. If it is lost, you rotate the key rather than recreate it.

Rotation without downtime.

Two secrets during the changeover

01

Start the rotation

A new secret is created for the same key with the same permissions. The old one keeps working for as long as you choose.

02

Swap it in the integration

You put the new secret in when it suits you. The log shows which of the two was used on each call.

03

Close the old one

Once all traffic has moved, the old secret is closed — immediately, or automatically when the overlap expires.

Keys can be managed through the API too.

Endpoints and examples

The endpoints require a key with the auth:rw permission, which only an administrator can create in admin. A key can never grant itself more permissions than it already has.

GET /v2/auth/keys List keys and permissions
POST /v2/auth/keys Create a key, secret in the response
POST /v2/auth/keys/{id}:rotate Rotate with an overlap
POST /v2/auth/keys/{id}/scopes Change permissions
DEL /v2/auth/keys/{id} Revoke immediately
GET /v2/auth/keys/{id}/usage Calls, errors and response times
keys.ts 
// Create a key for a new integration
const key = await hdl.auth.keys.create({
  name: 'Fortnox-sync',
  environment: 'live',
  scopes: ['order:rw', 'article:rw', 'stock:r'],
  expiresAt: '2027-01-14',
  ipAllowlist: ['81.230.44.0/24'],
  rateLimit: { perMinute: 600 },
});

// key.secret exists only in this response
// { id, prefix: 'hdl_live_7Kq2', secret: 'hdl_live_…' }

// Rotate with a 14-day overlap
await hdl.auth.keys.rotate(key.id, { overlapDays: 14 });
Measurement

What the key actually does.

Security

Built-in safeguards

The secret is shown once and stored hashed

Permissions per resource, read and write separately

IP restrictions and rate limits per key

Test and production have separate keys

Control

When something has to be closed

Revoke immediately and the calls stop working at once

An expiry date with a reminder before it passes

Webhook signing secrets rotate separately

Every change lands in the activity log

Questions about keys.

Common questions

What if we lose the secret?+

It cannot be shown again. You rotate the key instead, which gives a new secret with the same name and permissions — and an overlap so the integration can be changed without rushing.

Can an agency have its own key?+

Yes. Give the key only the permissions the work requires, set an expiry date and restrict it to their IP addresses. It can be revoked without touching your other integrations.

Are test and production keys separate?+

Yes. The prefix shows the environment, and a test key can never reach production data.

How do we tell whether an old key is still in use?+

The list shows the last call per key, and during a rotation it shows call counts per secret, so you can see when it is safe to close the old one.

What happens at the rate limit?+

Calls answer with a 429 and a Retry-After header. The limit is set per key so one integration cannot crowd out the others.

Can webhooks be signed?+

Yes. Every webhook endpoint has its own signing secret, rotated separately from the API keys.

Technical demo

Go through your key management.

We look at which integrations need which permissions, and set up rotation before you go live.