Skip to main content
The Reconify API authenticates every protected request with an organization API key. Keys start with rk_, belong to exactly one organization, and decide which organization’s data a request reaches.

​
Create an API key

Keys live in Dashboard → Settings → API Keys, where workspace owners and admins create and revoke them. The dashboard shows the secret once, at creation, and afterwards shows only the key name and display prefix. Storing the secret in your secret manager at that moment saves a rotation later:

​
Choose a scope

Each key carries one scope, and the scope decides which methods it reaches. A sender needs write. A reader needs read. An admin key fits the case where one service does both. The metadata routes GET /v2 and GET /v2/health answer without a key.

​
Send the key

The key travels in the Authorization header, over HTTPS, with the Bearer scheme:
cURL
That request also doubles as a key test. GET /v2 returns metadata without checking credentials, so a protected route is what tells you the key works. The API resolves the organization from the key itself. A caller cannot select another organization through a path, a query parameter, or a request body field.

​
When authentication fails

Two statuses cover every credential failure:
  • 401 Unauthorized means the header is missing, malformed, expired, revoked, or unknown.
  • 403 Forbidden means the key is valid but its scope does not cover the method.

​
Keep keys safe

A leaked key reads and writes financial evidence, so five habits matter:
  • Secrets belong in a secret manager or a runtime environment variable.
  • Each integration gets its own named key, which makes revocation surgical.
  • Keys travel only in the Authorization header, only over HTTPS.
  • Nothing commits a key to source control, a log, a ticket, or an AI prompt.
  • An exposed key gets rotated immediately, and Security covers the rest of the response.