API Keys & Integrations
Creating, scoping, and revoking API keys for your own integrations with Buyer24.
Overview
API keys let external systems interact with your Buyer24 organization. They're used for:
- Third-party integrations that need to create or read RFQs
- AI assistants like Claude, connected through the Buyer24 connector
- Automation workflows connecting Buyer24 to other tools
API keys belong to you, not to your organization — each person manages their own, and a key can only do what your own account can do. You'll find them under Profile → API Keys.
Creating an API Key
- Go to Profile → API Keys
- Click New token
- Enter a name that describes what will use it (e.g., "ERP Integration", "Weekly reporting script")
- Tick only the permissions that integration needs — see below
- Copy the generated key immediately — it is shown once and never again
Choosing what a key can do
This is the main security control, and it's worth a minute of thought.
A key does not automatically get everything you can do. You pick a specific
list of permissions when you create it, and the key can do nothing outside that
list — every request is checked against it. A reporting script given only read
permissions cannot create, edit, or send anything, even if it's compromised.
Permissions come in three kinds:
| Kind | Examples | What it means |
|---|---|---|
| Read | View your suppliers · View your RFQs and quotes | Can look, cannot change anything |
| Write | Create and update suppliers · Create and update RFQ drafts | Can change data inside Buyer24. Nothing leaves your organization |
| Send | Approve and send RFQs to suppliers · Email quotes to your customers | Sends real email to outside parties on your behalf |
The two sending permissions are the ones to be deliberate about. They are
never selected by default, and they're highlighted in the list. Everything else
a key does stops at the edge of your organization; these two don't. Leave them
off unless the integration's actual job is to send.
Permissions are fixed when the key is created. There is no way to edit
them afterwards. To change what a key can do, revoke it and create a new one —
which is also why one key per integration is easier to live with than one key
for everything.
Start smaller than you think you need. A key that's missing a permission
fails with a clear message naming what's missing, and creating a replacement
takes a few seconds. A key with more access than it needs fails silently — right
up until it doesn't.
What a key can never do
- Exceed your own access. A key runs as you. If you can't see another
organization's data, neither can the key.
- Manage other keys. A key cannot create, view, or revoke keys — including
itself. That needs a real login.
- Change your account. Your email address, name, password, sessions, and
connected apps are all off-limits to keys — those need a real login. This
matters: if a key could change your email, it could trigger a password reset
and take the account over.
Managing Keys
The API Keys page shows all active keys with:
- Name — The label you gave the key
- Created — When the key was generated
- Last used — When the key was last used to make a request
You can revoke a key at any time. Revoking a key immediately disables any integration using it.
Connecting Claude
If you want to connect Claude, you probably don't need a key from this page.
Claude connects by signing in to Buyer24 and approving access — no secret to copy,
paste, or rotate.
Full setup instructions for claude.ai, Claude Code, and Claude Desktop are in
Create a key here instead when you're building your own integration — an ERP
sync, a script, an internal tool — anything that isn't a Claude client.
Security Best Practices
- One key per integration — If your ERP system and an automation tool both connect to Buyer24, use separate keys. This way you can revoke one without affecting the other.
- Revoke unused keys — If an integration is decommissioned, revoke its key.
- Never expose keys in client-side code — Keep keys on the server side only.
- Check "Last used" — A key that hasn't been used in months is a candidate for revocation.
- Grant only what's needed — See Choosing what a key can do. Reporting needs read permissions only.
- Be deliberate about the sending permissions — They put mail in front of your suppliers and customers. Most integrations never need them.
- Rotate on people changes — Keys belong to the person who created them. When someone leaves, revoke the keys they made and re-create them under an owner who's still there.
Troubleshooting
| Symptom | Likely cause | What to do |
|---|---|---|
| Integration suddenly stops working | The key was revoked | Generate a new key and update the integration |
| "Unauthorized" errors | The key was copied incorrectly or is from a different environment | Re-copy the key; if lost, revoke it and generate a new one |
| "Permission denied" on a specific action | The key wasn't given that permission — and permissions can't be edited after creation | Create a new key with the permission ticked, update the integration, then revoke the old key |
| An integration can do everything except send | Working as designed — the sending permissions are never granted by default | Create a new key with the sending permission ticked, if the integration genuinely needs it |
Note: A key's value is only shown once, at creation. If you lose it, there's no way to view it again — revoke the old key and create a new one.