Do I need a special "API key"?
No. Bezala doesn't issue a separate API key per integration. Instead, every API call is authenticated as a specific Bezala user — using that user's credentials (email + password, or SSO token) to obtain a Bearer token via POST /api/auth/token.
This means: if you have a Bezala login, you have API access. You don't need to apply for anything, you don't need to wait, and you don't need to email support. Just call /api/auth/token with your credentials and you're in.
If you're new to the API, jump straight to quickstart and you'll have a working call in five minutes.
Account requirements
To use the API you need:
A Bezala account. Sign up at bezala.com if you don't already have one. A personal free company is enough for testing — it has the same endpoints as a paid company, just without a real bookkeeping integration attached.
An email and password, or an SSO login through Google, Microsoft, or Okta. See authentication for how SSO accounts authenticate to the API.
There's no plan-tier check to clear, no "API enablement" toggle in settings, and no developer-mode you have to switch on. Whatever your account can do in the web UI, the API can do.
Roles and what they let you call
Bezala has three role tiers. Your token's role determines which endpoints work for you:
Regular user — can read and write their own expenses, time entries, absences, and trips. Can't see other users' records.
Manager — everything a regular user can do, plus visibility and approval rights over the users they manage.
Accountant — visibility into every user's records in the company. Can trigger batches, edit bills and bill lines, and use the full export endpoints across the company.
For a personal integration (one developer automating their own expense submissions), a regular user is enough. For a company-wide integration (analytics ETL, accounting sync, ERP master-data mirror), you almost always want an accountant role on a dedicated service user.
Service users for production integrations
You can use your own Bezala login to test the API, but you should not use it for a production integration. A service user is a dedicated Bezala user, not tied to any human, that the integration logs in as. Two reasons this matters:
Real employees leave. When they do, their credentials get rotated and your integration breaks at 3am.
Audit trails get cleaner. Every change made by the integration is attributed to the service user — easy to spot manual changes versus automated ones, and easy to revoke when the integration is decommissioned.
Creating a service user is the same flow as inviting any other user — invite an email like [email protected], give it the role it needs (typically accountant), and store its password in your secrets manager.
If your company uses SSO and policy-blocks password login for any address in the SSO domain, see authentication for the three workable paths around that.
Multi-company users
A Bezala user can belong to several companies — common for accountants serving multiple clients, and for groups with multiple legal entities. Calls happen in whichever company is currently selected on the user's record.
For an integration that should only ever see one company, the safest pattern is a service user that's a member of only that company. There's nothing for the integration to accidentally pick up — even if it switches companies, there's only one to switch to.
For an integration that needs to span multiple companies (a group-level analytics pipeline, for example), the service user becomes a member of every company in scope. The integration switches the active company between calls using PUT /api/users/:id/change_company/:company_id. See authentication.
Where to look up your token later
There's no "show me my token" page in the Bezala UI. The POST /api/auth/token endpoint is the way to get a token, every time. Calling it again with the same credentials gives you a working token — so if you've forgotten where you stored the previous one, just call the endpoint again.
Common misconceptions
These all show up regularly in support; the docs should pre-empt them.
"I need to email support to get API access." No. The in-app chat may currently route requests there, but the actual mechanism is POST /api/auth/token and you can call it without anyone's help.
"I need a special API plan or contract." No. Every Bezala plan includes API access at the same shape.
"There's a separate API password." No. Your normal Bezala credentials work.
"API tokens expire after X hours." No. Tokens are long-lived; they don't expire on a fixed schedule. They get invalidated when the user's password changes or the user is removed. See authentication.
What's next
Once you have an account and you've thought about which user identity should make the calls, quickstart walks through the first request. After that, authentication covers the wire-level details (SSO, service users, multi-company switching) and conventions covers what every endpoint shares.