Organizations

Every Oligon account belongs to one or more organizations (orgs). The org is the unit of:

• Billing — one Stripe customer, one invoice, one usage meter.
• Access control — members, roles, audit log.
• Resource ownership — receipts, API keys, webhook endpoints.
• Isolation — Postgres row-level security guarantees that one org cannot read another org's data, even with a buggy app.

Anatomy

{
  "id": "org_01HQX...",
  "name": "Acme Receipts Inc.",
  "slug": "acme-receipts",
  "plan": "startup",
  "stripe_customer_id": "cus_...",
  "created_at": "2026-04-01T12:00:00Z"
}

• slug is unique and URL-safe; it appears in the portal path (oligontech.com/portal/<slug>).
• plan is one of free, indie, startup, scale, enterprise.

Common operations

• Switch org — every API key is bound to a single org, so just use the matching key. The portal's org switcher swaps the active key.
• Rename — PATCH /v1/org { "name": "..." }. Slug is immutable.
• Invite teammates — POST /v1/team/invites with email + role. See the team & roles page.

When to create more than one org

• Separate environments — acme-prod vs acme-staging keeps test data out of production reports.
• Customer-facing isolation — if you build a B2B2C product on top of Oligon, create one org per your customer and route their keys.

For high-volume sub-tenant flows, see Multi-tenancy patterns — there is a more efficient model than creating an org per end-user.