Create an API key

With an API key, your own software works with the data of your sites, for example to publish vacancies from your HR system. The key is like a password for software, with the rights you choose. An AI assistant doesn't need a key: it connects through the MCP, with your account. See Edit your site with your AI assistant.

Before you start

• Who: the owner or an admin of the organization. An editor, designer or member can't see the API keys.

• Plan: any plan.

• You need: to know which integration gets the key and what it must be able to do, and a safe place to store it, such as a password manager.

Create a key

1. Sign in at app.kintsu.be and go to Organization › Settings › API keys.

2. Under Name, enter what the key is for, for example “Accounting link”. That way, you'll know later what's using it.

3. Under Rights, only tick what the integration needs. See below.

4. Under Valid for, choose a term: 30 days, 90 days (the default), 365 days or No end date. We recommend 90 or 365 days.

5. Click Create key. If you signed in a while ago, Kintsu first asks for your password in Confirm it is you.

6. You'll see: “Copy the key now: it is shown only once.” Click Copy.

7. Store the key in a safe place right away.

Note: Kintsu doesn't keep the key itself, only an irreversible fingerprint. So nobody can display it again. Lost it? Create a new one and delete the old one.

Which rights should you choose?

You only see the rights your own role has: a key never gets more than you. The API uses four of them:

• site.read: read your sites, tables and items.

• content.edit: create, change and move items to the bin, including many at once with your own id, and upload files.

• content.publish: put drafts online.

• submission.read: read your form submissions.

The API doesn't currently use the other rights in the list, such as domain.manage. Leave them off. Always choose the minimum: an integration that only shows your vacancies only needs site.read.

Test the key

Put the key in an environment variable and ask Kintsu who it works for. On macOS or Linux, in the terminal:

export KINTSU_API_KEY="paste-your-key-here"

curl https://app.kintsu.be/api/v1/whoami -H "Authorization: Bearer $KINTSU_API_KEY"

On Windows, in PowerShell:

$env:KINTSU_API_KEY = "paste-your-key-here"

curl.exe https://app.kintsu.be/api/v1/whoami -H "Authorization: Bearer $env:KINTSU_API_KEY"

The response shows your organization, the name of the key and its rights, for example:

{"organization": {"id": "…", "name": "Bakkerij Peeters", "slug": "bakkerij-peeters"}, "key": {"id": "…", "name": "Accounting link"}, "permissions": {"site": ["read"]}}

Got an error? See Not working? at the bottom.

Store and share it safely

• Keep the key in a password manager, or in your server's secrets (an environment variable or a vault). Never in the code of a website or app, and never in Git.

• Only use it on a server, never in a browser or a phone app: anyone could read it there.

• Never send it by email, chat or screenshot. Give it to a developer through a password manager or a one-time link.

• Create one key per integration or per developer. That way, you can revoke one without affecting the others.

When does a key stop working?

A key works for the person who created it, with at most the rights that person has at that moment. It stops working immediately if:

• its term is over (the list then shows Expired);

• someone deletes it;

• the person who created it leaves the organization or is removed from it;

• that person's role requires two-step verification and it's turned off.

If that person gets a lower role, the key loses the rights that role doesn't have. So create keys for long-term integrations with an account that will stay, such as the managing director's.

Review

Under Keys of the organization, you can see each key's name, the start of the key, its rights, who created it and when, how long it's valid and when it was last used. Delete what you no longer use. An organization can have at most 50 keys.

Renew without downtime

There's no button to renew a key. Here's how to do it, well before the old one expires:

1. Create a new key with the same rights.

2. Put the new key in your integration.

3. Test with whoami and check that your integration works. In the list, the new key shows when it was last used.

4. Delete the old key.

Revoke a key

Click Delete next to the key. It stops working immediately: any software using it gets a 401 error from then on.

Leaked?

Did the key end up in an email, a chat, a screenshot or code on GitHub?

1. Delete it right away, even if you're not sure anyone saw it.

2. Create a new key and put it in your integration.

3. Check what happened: in Organization › Settings › Audit log, and in the editor's History. Changes made with a key are marked “through the API” there.

4. Undo anything that's wrong, or go back to an earlier publication. See Publishing and undoing.

Not working?

• 401 with the code API_KEY_INVALID: the key is missing, wrong, expired or deleted, or its creator is no longer a member. Also check that the header is exactly Authorization: Bearer, followed by the key.

• 403 with the code forbidden: the key lacks the right for this request. Create a new one with the correct right.

• 403 with the code API_ORGANIZATION_SUSPENDED: the organization is suspended.

• 403 with the code READ_ONLY: a payment is overdue or the subscription has ended. Reading still works, changing doesn't. The owner can sort this out under Subscription.

• 429 with the code API_RATE_LIMITED: more than 120 requests per minute with this key. Wait for the number of seconds given in the Retry-After header.

• “Your role has no rights of the app to give a key.” Ask the owner.

• “An organization has at most 50 API keys.” Delete keys you no longer use.

With your AI assistant

An assistant can't create keys, and you shouldn't give it one in a chat either. Ask it for a script instead: “Write a script that fetches my vacancies from Kintsu with the API. Read the key from the environment variable KINTSU_API_KEY.”

More about the API: The API for developers and the reference.

Checked on 4 November 2026.