Resources
Documents, signatures and agents
Three list-only resources, deliberately narrow.
GET /documents?scope=&status=&type=&lead_id=&operation_id=&property_id=
GET /signatures?status=&template=&operation_id=&property_id=&signer_email=
GET /agents?role=&office_id=&email=
signer_email and email match case-insensitively.
List-only, on purpose
Each has its own serializer naming every field it returns. None is a
select *. What they leave out is the point:
- a document exposes its file reference, but no storage path and no download URL;
- a signature exposes its status and its signer, but never the signing token, the PDF path, or the variables blob it was rendered from;
- an agent exposes the professional identity a Zap needs to route work — name, email, role, office — and nothing else.
An integration can learn that a mandate was signed without being handed the means to open it.
And their write permissions do not exist
documents:write, signatures:write and agents:write are in the vocabulary so
the grammar stays uniform and a future endpoint needs no migration. Today no
route consumes them: granting them buys nothing.
A document's status has two values that both mean "done": received and
verified. A filter that compares only against received leaves whatever
someone already verified stuck.
The connected identity
curl "$ORKASA_API/me" -H "Authorization: Bearer $ORKASA_KEY"{
"brokerage_id": "0d1f…",
"brokerage_name": "Casa Móvil Panamá",
"scopes": ["leads:read", "leads:write", "operations:read"]
}GET /me sits outside the resource set and returns a flat object, with no
data envelope, so Zapier can use it as-is as the connection test and label. It
requires leads:read.