Scopes & entitlements
Access to a partner endpoint is governed by two independent checks. Both must pass.
Scopes — what your key may call
Section titled “Scopes — what your key may call”A key carries a list of scopes, chosen when the key is issued. Each scope maps to one
service:
| Scope | Service |
|---|---|
progression |
Tenancy progression (OpenFlow) |
rent_ready |
Pre-qualification / rent-ready |
maintenance |
Maintenance issues |
portal |
Property portal (leads & listings) |
Calling an endpoint whose service isn’t in your key’s scopes returns:
{ "status": false, "message": "This API key does not have the '<scope>' scope." }A key can be narrow (one scope) or broad (several). Scopes only ever restrict — they never grant access your brand isn’t entitled to.
Entitlements — what your brand offers
Section titled “Entitlements — what your brand offers”Independently of the key, your brand has an entitlement per service, configured by OpenBrix. If your brand isn’t entitled to a service, calls to it are rejected even if your key holds the scope. This is what lets a partner switch a service off entirely.
Data isolation
Section titled “Data isolation”Once your key is verified, it resolves — server-side — to your own company. Every query is then scoped to that company:
- List endpoints return only your company’s records (an empty list if you have none).
- Record endpoints (
/.../{id}) reject an id that doesn’t belong to you, rather than leaking it.
You cannot widen this by any request parameter, header, or body field — the company is derived from the key, not from the request. Cross-partner access is not possible.
Disabling one service never breaks another
Section titled “Disabling one service never breaks another”Services are decoupled. If your brand turns off (or your key omits) one service, every other service you use keeps working end-to-end. Opting out of, say, referencing to use your own external supplier does not degrade progression, maintenance or the portal.