Skip to main content
The BrikSync PropOS API authenticates every request with an API key, sent as a bearer token. There is no separate login flow for the API — a key you create is a standing credential you attach to each request.
API keys are a Business plan feature. Creating and revoking a key requires the Admin access level within your organisation.

​
Creating a key

  1. Go to API & Automation in the left sidebar.
  2. Click New key.
  3. Name it for what it’s for (for example, “Zapier sync” or “Claude assistant”).
  4. Choose an access level — this is the ceiling on what the key can ever do, described below.
  5. Choose the scopes the key needs — only the specific things it should be able to read or suggest.
  6. Click Create.
The key’s secret value is shown exactly once, right after creation. Copy it into a password manager or your integration’s configuration immediately — BrikSync stores only a fingerprint of the key, not the key itself, so there is no way to retrieve it again later. If you lose it, revoke the key and create a new one.

​
Sending your key

Attach the key to every request as an Authorization header:
A missing or malformed header returns unauthenticated. An invalid, revoked, or expired key returns invalid_credentials, credential_revoked, or credential_expired respectively — see Errors & Limits for the full list.

​
Access levels

Every key is issued at one of these access levels, matching the roles in BrikSync itself. The level sets the outer boundary on what the key’s requests can ever see or do — a key can never see more than that level would see inside BrikSync, no matter which scopes are attached to it.
Access level is a ceiling, never a grant. Scopes narrow what a key can ask for within that ceiling — they never widen it beyond what the access level already allows.

​
Scopes

Scopes are the specific things a key is allowed to ask for. When you create a key, you choose only the scopes it needs — an integration that reads your rent roll for a spreadsheet has no reason to hold a scope that can also suggest changes to leases.
Notice there is no scope that writes a property, a lease, a tenant, or a payment directly. That’s deliberate — see Suggesting Changes for why, and how the approval step works.
A request that needs a scope the key doesn’t have returns insufficient_scope. Scopes are matched exactly — there is no scope that implies another, so a key with properties:read cannot also read units, and a key with leases:read cannot propose changes to leases without leases:propose as well.

​
Revoking a key

From API & Automation, an Admin can revoke any key at any time. A revoked key stops working immediately on its next request — there is no grace period. If an integration needs to keep working, create a new key and update the integration before revoking the old one.

​
Best practices

  • One key per integration. Don’t share a key between two different tools — if you need to rotate or revoke one, you can do it without breaking the other.
  • Use the narrowest access level and scopes that work. A key only needs properties:read if that’s all the integration does.
  • Store the secret in a secrets manager or environment variable, never in code you commit or share.
  • Revoke keys you no longer use. An unused key is still a working credential until you revoke it.

​
Next steps

Reading Data

Collections, pagination, filtering, and example requests.

Suggesting Changes

How proposals work and why the API can never write directly.
BrikSync is in private beta and not yet incorporated — we are working through that process and building a small founding team.
Last modified on August 20, 2026