Tenants & Members

Every ERIP customer is a tenant - a firm, desk, or team. Billing, credits, and contact data all live at tenant scope; members of the same tenant share one pool.

Entity model

One user belongs to exactly one tenant. If a person genuinely needs access to two tenants, they create two accounts.

Tenant roles

Every user carries one of two roles within their tenant:

• Admin - manages members, service keys, and tenant contact info.
• Member - uses the API; can mint their own user API keys.

The first user of a newly provisioned tenant is always an Admin; subsequent members default to Member unless the inviter specifies otherwise when sending the invite.

Lifecycle

1. Tenant provisioning

ERIP staff create the tenant and its first admin. The admin is created in PendingInvite status and receives an email:

You've been invited to Acme Capital Partners on ERIP - click to activate your account.

There is no self-service tenant signup. All tenants go through this workflow.

2. Invite acceptance

Opening the invite link clears the invite token, flips the user to Active, and emails them a short-lived magic link. Clicking the magic link returns a JWT - the user is now signed in.

3. Adding teammates

A tenant admin invites new members from within the tenant:

curl -X POST https://api.erip.io/v1/tenant/users \
  -H "Authorization: Bearer YOUR_JWT" \
  -H "Content-Type: application/json" \
  -d '{"name": "Bob", "email": "bob@acme.test", "tenantRole": "Member"}'

Bob receives the same invite → magic-link flow as the first admin. He inherits the tenant's tier and credit pool immediately.

4. Removing teammates

curl -X DELETE https://api.erip.io/v1/tenant/users/{userId} \
  -H "Authorization: Bearer YOUR_JWT"

The user is suspended and all their API keys deactivated in one operation. Credits already consumed are kept in the transaction history for audit.

Service API keys

User-owned API keys die when the user is suspended - fine for interactive API use but awkward for CI, data pipelines, and long-lived integrations. Tenant service keys solve this:

Either key type authenticates to /v1/companies/** and the MCP server. Neither can hit tenant-admin endpoints - those are JWT-only. See Authentication for the full scheme matrix.

Create a service key

curl -X POST https://api.erip.io/v1/tenant/api-keys/service \
  -H "Authorization: Bearer YOUR_JWT" \
  -H "Content-Type: application/json" \
  -d '{"name": "Daily ingest job"}'

The raw key is returned exactly once. List existing keys with GET /v1/tenant/api-keys/service and revoke with DELETE /v1/tenant/api-keys/service/{keyId}.

Credits

Credits live on the tenant. A deduction records both the tenant (for billing) and the user (for per-seat usage reporting); service-key calls record userId: null. See GET /v1/tenant/credits/history for the full attributed log.

Changing tier resets the tenant's balance to the new tier's monthly allocation - a PeriodReset transaction is written to the history so the change is auditable.

Tenant contact & billing

Each tenant carries contact and campaign-consent data that customers (tenant admins) can maintain:

curl -X PATCH https://api.erip.io/v1/tenant/contact \
  -H "Authorization: Bearer YOUR_JWT" \
  -H "Content-Type: application/json" \
  -d '{"billingEmail": "finance@acme.test", "industry": "PrivateCredit", "marketingConsent": true, "marketingConsentSource": "signup-form"}'

Marketing consent toggles also stamp marketingConsentAt server-side, giving you a GDPR-grade provenance trail.