Finero has two ways in, and choosing between them is the first real decision of any integration. They are not two spellings of the same thing: they authenticate different subjects and they grant different authority.
An API key acts as the workspace. An OAuth 2.1 session acts as the person who approved it. Pick the one that matches who is actually responsible for the call.
Canonical location
The generated reference documents the exact header and its format. This page covers which credential to use and how to get one.
Which credential to use
- API key, for unattended systems. A sync job, a backend service, a scheduled reconciliation. There is no person in the loop, so workspace authority is the honest description of what is happening. Use the HTTP API.
- OAuth 2.1, for assistants. An AI assistant acting for one person, through the MCP server. Read-mostly, a smaller capability set, and bounded by what that person approved.
The rule of thumb: if you already hold an API key, use the HTTP API. Routing a backend service through an assistant-shaped session adds a consent step that has nobody to consent to it.
Getting a key without talking to anyone
Keys are self-serve. In the application, go to Settings and then API, create a key, and copy it. It is shown once, on creation, so store it before closing the dialog. The same screen lists existing keys and revokes them.
Store it server-side and nowhere else. A workspace key in a client bundle or a mobile app is readable by anyone who opens developer tools, and it carries the authority of the entire workspace rather than one user. Environment variable or secret manager, the same as a database password.
To rotate: create the replacement, deploy it, then revoke the old key. Revoking first gives you an outage in between. Keys do not expire on their own today, so rotation is something you schedule rather than something that happens to you.
How an agent discovers the authorisation chain
Nothing needs to be hardcoded. The chain is discoverable from a single refused request, which is the point of the standards involved:
- An unauthenticated request to the MCP endpoint returns 401 with a WWW-Authenticate header naming its protected-resource metadata document.
- That document is RFC 9728 protected-resource metadata. It names the authorization server and the bearer method. Its scopes_supported is the standard OpenID set, not a list of Finero capabilities: access granularity is the consent screen, and a product-shaped scope string is refused rather than honoured.
- The authorization server publishes its own RFC 8414 metadata, from which the client learns the endpoints it needs. At no point does a client guess a URL.
- What discovery does not provide is a client ID. Finero registers OAuth clients in advance rather than offering dynamic registration, so an administrator creates one under Settings, then API & agents, and hands the assistant the ID and secret. Discovery establishes where to authorise; who is asking is settled beforehand.
If you would rather not provoke a 401 to learn this, start at /.well-known/api-catalog. It is an RFC 9727 Linkset naming every Finero API surface and the document that describes each one, including the protected-resource metadata above.
What does not exist
There is no sandbox environment, no CLI, and no automatic key expiry. Said plainly here because the alternative is discovering it midway through an integration. If any of the three ships, this sentence changes; it will not be pre-announced.