Feature
API, integrations and security
A REST API with scoped keys, signed outbound webhooks, and a security model where tenant isolation is enforced by the database. Integrations sit behind interfaces with mocks, so nothing depends on a provider being configured.
The problem
Operators need their data out, and their data kept apart.
Most suites offer one or the other: an API at the top tier, or isolation you have to take on faith. Both should be standard.
- API access is gated to the most expensive plan.
- Multi-tenant isolation is an application-layer promise.
- Audit logs can be edited by the people they audit.
- Integrations are hard-wired to one vendor.
The workflow
How the pieces fit
- Isolation in the database
Every tenant table is forced to row-level security with deny-by-default policies. A missing tenant context returns zero rows. Support mode is org-scoped and audited — there is no bypass path.
- Roles and permissions
Platform admin, property manager, accounting, leasing agent, maintenance supervisor, owner, resident, vendor — with per-user overrides and portfolio scoping.
- API keys and webhooks
Keys are hashed at rest, scoped, rate-limited per key, and rotate with a 24-hour grace window. Webhooks are HMAC-signed.
- Integrations behind interfaces
Stripe, SMTP, SMS, push, S3-compatible storage, screening CRA, AI provider — each with a deterministic mock and a health indicator.
- Everything audited
Every write lands in an append-only audit log; money and signature tables are append-only at the database level.
Illustrative key management. See the security page for the full control inventory.
Capabilities
What is built, what needs configuration, what is planned
Each row is a real capability in the current build. Labels are derived from the codebase and its test suites, not from a roadmap deck.
How to read the labels
- Built
- Implemented in the current build and covered by its test suite.
- With configured integration
- Implemented; a live outcome requires a provider you configure (keys, contract, or credentials).
- Pilot
- Implemented in part and enabled per pilot customer with tuning.
- Planned
- On the roadmap. Not sold or promised today.
-
Public REST API v1 with scoped keys
BuiltHashed API keys with scopes, per-key rate limits, rotation with a 24-hour grace window; read endpoints plus ticket and charge writes.
-
Outbound webhooks (HMAC-signed)
BuiltRegister endpoints for domain events; deliveries carry an HMAC signature.
-
PostgreSQL row-level tenant isolation
BuiltEvery tenant table is forced to row-level security with deny-by-default policies; a missing tenant context returns zero rows.
-
Roles and permission overrides
BuiltPlatform admin, property manager, accounting, leasing agent, maintenance supervisor, owner, resident and vendor, with per-user permission overrides and portfolio scoping.
-
Append-only audit log
BuiltEvery write is audited; money and signature tables are append-only at the database level.
-
MFA, lockout and session controls
BuiltTOTP MFA with backup codes and trusted devices, credential lockout, forced rotation and session management.
-
SSO (SAML / OIDC)
PlannedEnterprise single sign-on.
-
Provider integrations
With configured integrationStripe (payments), SMTP email, SMS, push (FCM/APNs), S3-compatible storage, screening CRA, AI provider — each behind an interface with a mock, enabled by configuration.
By role
What each party gets
Operators
Their data is theirs: exportable through the API, isolated by the database.
Integrators
Read endpoints plus ticket and charge writes on v1, signed webhooks, and predictable rate limits.
Auditors
An append-only log of who did what, and a documented threat model.
Configuration and pilot notes
Before you rely on it
Things that are set up per operator during a pilot, or that depend on a provider you contract.
- API v1 covers reads plus ticket and charge writes; broader write scope is being extended.
- Provider integrations are enabled by configuration; none is a prerequisite for using the platform.
- SSO (SAML / OIDC) is planned.
- Rate limits are per-process today; a shared limiter is planned for multi-instance deployments.
Questions about this area
Do you have pre-built integrations with AppFolio, Buildium, Rent Manager or Yardi?
No. Migration from those systems is done through CSV exports during a pilot. We do not claim parity or integration with them.
Is the API included in every plan?
API access is part of the pilot and growth concepts on the pricing page; final commercial terms are agreed per operator.
Related
Connected areas
Read the security model, then ask us the hard questions.
The security page lists shipped controls, planned controls and residual risks in plain language.