Your platform. A trusted business context.

Three relationships, explicit access

Partner → business

A partner needs a delegated grant to the specific business and capability. Owning a customer relationship is not blanket access to its financial records.

User → business

A verified user needs active membership and an allowed role. A requested business ID is a selector, never proof of access.

Session → environment

A session must be bound to its audience and test/live environment, with expiration and revocation checked on the server.

Planned onboarding sequence

1. Provision safely

   The partner backend creates or resolves a business using a stable external reference scoped to that partner. Retrying must not create a second business.

2. Resolve membership

   Grant only permitted roles. Protect the last owner and reject role escalation or an absent delegated grant.

3. Establish a scoped session

   Use a short-lived, single-use handoff with server validation. Exact transport and expiry values will be published with the implementation.

4. Recheck each request

   Verify current membership, grant, role and environment. Clearing browser state must prevent old business data appearing after a switch.

Credentials stay behind the platform

Partner secrets belong in backend secret storage. Customer sessions cannot expose partner, database, Stripe or Xero credentials. Token storage, allowed origins, session revocation and CSRF protections must be verified before an embedded session is released.

Required acceptance

Tests must cover two unrelated businesses, one user in several businesses, revoked membership, expired handoff, replay, absent partner grant and role escalation. Direct-membership metadata isolation is tested in the API and real PostgreSQL. The preview does not establish partner grants, embedded sessions or financial permissions.