Architecture
Use the components you need. Keep the identity, authorisation and infrastructure you already have where they fit.
CustomAPIs provides the reusable backend foundations for secure multi-tenant APIs: tenant isolation, scoped authorisation, audit trails, generated documentation and committed-write events. Each API remains your service, deployed in your infrastructure: your Node.js process, your PostgreSQL database, your business logic. Keep what already works; adopt the pieces you need.
The same architecture also serves owner-scoped data and single-customer deployments — multi-tenancy is the centre of gravity, not an obligation.
Four problems decide whether a multi-tenant backend is safe to build on:
This architecture answers each one structurally rather than by convention. Here it is in one picture — the data plane (your APIs, your data) and the optional control plane that governs access:
The tenant is the primary ownership and isolation boundary for business data. Isolation is derived from your own data model and enforced inside the queries that load data — never a filter a developer remembers to write.
Your identity provider proves who is calling; what they may do, and where, is a separate decision. Authorisation can come from the provider’s claims, your existing IAM, or Access Management.
A decision is the set of tenants where a permission holds, resolved once per request and enforced identically on single records and list queries. The detail view and the list view cannot disagree about who sees what.
The framework provides enforcement mechanics; your decisions stay in ordinary application code, inside the request pipeline — never pushed into stored procedures or sidecars.
Authentication on, tenant scoping enforced, events off, docs private — omission never opts into risk. Every grant names a place; an absent or empty scope denies; platform-wide capability is a separate, visible, audited category.
Security- and business-relevant actions produce structured, append-only, queryable records — with an enforced human justification where routes demand it. Diagnostic logging is a separate, swappable concern; audit outlives it.
Each component has its own page, carrying its claims in full.
Your API service with the framework inside: derived tenant isolation, scoped authorisation, validation, audit and events — around your domain models and your rules.
A control plane for scopes, roles, grants and provisioning across many APIs — where every grant names a place and platform capability is explicit.
Bring your identity provider. One resolution seam, cached safely, with an agreed outage posture.
Structured, append-only, queryable records — with an enforced human “why” where routes demand it.
Everything in the runtime path runs in your infrastructure; PostgreSQL is the only hard dependency.
Committed-write events published to the event infrastructure you connect — transport stays yours.
A section on this page
Permission-aware documentation, self-correcting errors and installable skills — from the same metadata that secures the runtime.
Part of the tenant API page
The framework is built for relational products on Node.js and PostgreSQL, where tenant ownership runs through the model relationships and the expensive failures are cross-tenant disclosure and a change nobody can explain. Multi-tenancy is a choice rather than a requirement: rows can be owner-scoped — private to the user who owns them, with administrative access only through an explicit permission — and the same service shape runs single-customer deployments. We build the API and deliver it into your infrastructure; the shape it needs from your domain, the needs it answers, and the products that should look elsewhere are set out on the tenant API page.
Every component is independently adoptable, and every integration point is a seam with a working default, so a service can move from standalone to centrally governed without redesign. Five combinations cover most estates.
One tenant API with the framework inside; authorisation synthesised from your identity provider’s claims — a legitimate end state.
your identity provider (yours)the framework (adopted)
Your existing IAM answers one resolve contract; your users, roles and admin tooling stay where they are.
your identity provider (yours)your IAM (yours)the framework (adopted)
The full control plane: declared hierarchies, roles, grants, delegation with a ceiling, provisioning and access audit.
your identity provider (yours)the framework (adopted)Access Management (adopted)
Multiple APIs — framework-built or existing — under one administration, each keeping its own schema, rules and deployment.
your identity provider (yours)existing APIs (yours)tenant APIs (adopted)Access Management (adopted)
We help choose and design the event backbone your APIs publish into: Kafka, SNS/EventBridge or webhooks, sized to your integrations. It runs in your account and remains yours.
your event infrastructure (yours)consultation & design (adopted)
Tenant APIs publish events only after the transaction commits — a published event never corresponds to a rolled-back write. Each event carries a stable envelope, including the same correlation identifier that ties the action’s audit record and log lines together. And events are semantic, not just row changes: applications name the business occurrences that matter, alongside record-change events.
Transport stays yours. The framework defines emission and the envelope, and publishes to the event infrastructure you already run — Kafka, SNS or EventBridge, or webhooks. Access is governed the same way as everything else: the same scoped grants that govern synchronous calls govern who may subscribe and whose events they receive.
The event infrastructure itself is optional. If you don’t run one yet, we help design and stand it up as part of an engagement — in your account, and it remains yours.
Everything in the runtime path runs in your infrastructure: stateless services with the framework embedded, PostgreSQL (the only hard runtime dependency), and the scheduler, secret store and event transport you already operate. Nothing runs in a vendor account, so data residency holds by construction. Your identity provider stays exactly where it is, and Access Management is architecturally a separate service, consulted for cached access decisions. Seams, trust boundaries and failure behaviour are covered on the deployment page.
The framework is proprietary software, actively developed and delivered through engagements — not an open-source download. Your licence to the delivered system is perpetual: if the relationship ends, what’s deployed remains yours to run, with terms on the Core Package page. Start a conversation to see it against your own domain: the API surface, the generated documentation, the audit trail. We walk it through for scenarios like yours.