orkasa
ESEntrar

Authentication

API keys

One credential per brokerage, with the permissions you ask for.

Authorization: Bearer ork_live_<40 characters>

A key belongs to one brokerage and carries its permission list. Orkasa issues it: write to us through the contact form saying what your integration needs to read or write.

The key is shown once. Only a SHA-256 digest is stored, so nobody — you included — can recover it afterwards. If it is lost, it is revoked and a new one is issued.

Permissions

<resource>:read and <resource>:write over eight resources: leads, operations, properties, viewings, offers, documents, signatures, agents. * grants everything. A missing permission is 403 forbidden.

documents, signatures and agents are list-only. Their :write half exists in the vocabulary — so the grammar stays uniform and a future endpoint needs no migration — but no route consumes it today: granting it buys nothing.

One vocabulary serves both credential types: a key stores these strings on its row, OAuth passes the same ones space-separated in its scope parameter.

A key only ever sees its own brokerage

An id from another brokerage is answered 404 not_found, never 403. And a key has no author: it stands for the whole brokerage, not for one agent. That is the difference with the MCP connector, where the assistant additionally inherits the scope of the person who authorized it — see Connector permissions.

Test the credential

curl "https://orkasa.app/api/v1/me" -H "Authorization: Bearer $ORKASA_KEY"
{
  "brokerage_id": "0d1f…",
  "brokerage_name": "Casa Móvil Panamá",
  "scopes": ["leads:read", "leads:write", "operations:read"]
}

Requires leads:read. It is what Zapier uses to verify and label the connection.