B2B & SaaS Application Infrastructure

Start with a multi-tenant API framework that's secure from the first request.

Design your database and expose what you need through a REST API, with customer boundaries, controlled access, a trusted record of change and business events built in.

One foundation supports your products, workflows and integrations. The same permissions and business events apply whether work stays within your business or is shared with customers and partners.

Your UI can move forward from the start, while development effort goes into the parts of the product that make your business different.

Discuss your system Try the live demo

The demo is a real API. Call it from your browser or hand it to an AI agent. No signup.

See how the multi-tenant API works →

Runs in your AWS account under a perpetual licence you keep.

The Tenant API

Build the product, not the groundwork.

In most relational systems the majority of routes do the same handful of things. We start from a proven backend framework that already handles those patterns, then concentrate effort on the behaviour that is specific to your business.

Get the common API surface running early

Most routes are variations on create, read, update, archive and search. Each one also has to check access, record an audit trail, publish an event and return a consistent response. The framework handles all of that, so a new resource takes three steps:

Create your table. Use your own schema and migration tool, and the models are generated from the database.
Expose its routes. Each route is a declaration naming the model and the operation, or you can generate the standard set in one command.
Give users permission. Every route checks sign-in and permission by default, so nothing is reachable until you grant it.

You get a working, consistent foundation early, without locking out the customisation that comes next.

Custom where it matters

Standardised does not mean inflexible. The framework handles the common lifecycle consistently while providing clear extension points for customer-specific behaviour:

Hide fields from particular users or applications
Make fields read-only
Apply additional validation to create or update operations
Calculate values from related records
Restrict access through tenant or organisational relationships
Run custom business logic at any stage of the request lifecycle after sign-in and permission checks
Add specialised searches or custom operations
Change the event payload available to an integration partner

Capabilities

What the Tenant API takes care of

Customer boundaries and controlled access

Access control should not depend on every developer remembering every check. Tenant isolation is derived from how your data relates, so it is applied the same way on every route rather than re-checked by hand. The same permission model then determines what a user or integration may read, change and receive:

Route and operation-specific permissions
Tenant isolation and record-level access
Access through related relational data
Human and machine identity checks
Field visibility
Event topic and payload permissions

Tenant isolation architecture →

A trusted record of change

Important operations should leave a reliable history. Because auditing is part of the framework lifecycle, it does not need to be reimplemented for every endpoint:

Who or what performed the operation
Which tenant and record were affected
What operation occurred, and when
Relevant request and change information
Whether the actor was a human or machine identity
The result of the operation

The audit architecture →

Events that connect your business

Events are part of the framework, not an afterthought. Your system publishes business events from day one, to topics that are permissioned resources under the same model as your API — so what a user or integration partner may see through the API is what they may see through your events. A delivery connector hands those events to your platform — your Kafka, Amazon SNS or EventBridge — from where onward access is governed by your platform and shared with partners.

Integrations can also map their own IDs onto your records — namespaced and tenant-scoped — so third-party systems stay in sync without custom plumbing.

Tenant-scoped integration keys →

How events fit the architecture →

Documentation that stays accurate

API documentation is generated from the same executable definitions that run the API, substantially reducing the risk of drift from the real behaviour. It is permission-aware: each consumer sees documentation for exactly the routes they are allowed to call — which makes onboarding your frontend team and your partners’ integration engineers faster and less error-prone.

Permission-aware documentation →

Works with your identity provider

Your system always defines and enforces its own permissions. Users sign in with JWTs from your existing identity provider, set up when the API is scaffolded. Permission assignment — who holds which permission, in which part of your organisation — can be delivered with the system or driven from a system you already run, and moving between the two later is configuration rather than a rewrite.

Identity integration in the architecture →

Scales without changing shape

Different systems reach scale in different ways. The Tenant API has levers at every layer: lean responses and capped queries in the API, horizontal scaling of the application tier, and larger database instances and read replicas. The right combination depends on the workload, and not every performance problem needs more infrastructure.

How the API scales →

The deployment architecture →

Try it

Call it from the command line, an AI agent or your own code

The demo is a live Tenant API with its keys on the page. Call it with curl, hand it to an AI agent, generate a client from its OpenAPI document, or work through it in your browser.

Try the live demo

Fit

Built for connected B2B systems

Multi-tenancy that follows your data

B2B data is connected: records belong to other records, all the way up to the customer that owns them:

Organisation
  └─ Location
       └─ Department
            └─ Employee
                 └─ Timesheet
                      └─ Invoice

These relationships often determine who owns a record, which tenant it belongs to, who may view or change it, which records appear in a search, and which events an integration partner may receive. Rather than reducing the system to disconnected endpoints, the Tenant API is built around those relationships.

How tenant isolation is derived →

How access follows your structure →

Where it fits best

The Tenant API fits best when your product is built on a relational database, most routes follow repeatable business-data patterns, and you need a usable API surface quickly — but still need real customisation, consistent tenant isolation, auditing and secure event publishing for customers or partners. It suits teams who already have frontend, mobile or product capability and want a secure and well-engineered backend. Discovery establishes whether it fits; sometimes building internally or choosing another platform will be the better answer.

Where the framework fits — and where it doesn’t →

Build or adopt

Build the platform foundations yourself — or start from ours?

There is risk either way. Building internally gives you complete control, but requires experienced people, architectural decisions and an ongoing commitment to maintain everything you create. Starting from our foundation reduces staffing, architecture and delivery risk, but introduces a dependency on an external specialist.

The right decision depends on the capability you already have, how quickly you need to move and which risks your business is best placed to own.

Consideration	Build internally	Start from the CustomAPIs foundation
Architecture	Your team has complete design freedom, but must work through tenancy, permissions, auditing, events, integrations and operational concerns itself. Important mistakes may only become visible after the system is in use.	The principal has designed a scalable system with a production-proven multi-tenant architecture. The remaining risk is whether the approach fits your particular system, which we assess before committing to the build.
People	You develop the capability internally, but may need to recruit experienced backend and platform engineers or divert them from work already on your roadmap.	You can begin with relevant experience already available, without first committing to long-term hiring. The trade-off is a dependency on a specialist supplier.
Delivery	Delivery can be fast if the right team is already available. Otherwise recruitment, architecture and foundational engineering delay the business-specific work.	The common API surface can be running early because the foundations already exist. Custom rules, integrations and workflows still affect the complete delivery time.
Cost	Existing salaries can make the work appear inexpensive, but the real cost includes opportunity cost, maintenance, operational ownership and possible rework.	There is a visible upfront cost, followed by separately identified costs for support, operations and further development. It is most likely to be economically attractive when the alternative is assembling or redirecting equivalent specialist capability.
Fit and flexibility	Your team can design without framework constraints, provided it has the time and experience required.	The foundation is deliberately opinionated and best suited to relational, multi-tenant business systems. Discovery establishes whether it fits; sometimes building internally or choosing another platform will be the better answer.
Control and dependency	You control the application source, but still depend on employees, open-source and commercial packages, cloud services and retained internal knowledge.	You control the AWS account, infrastructure, data and application-specific source. The underlying CustomAPIs library remains proprietary, but the licensed version runs in your account and does not depend on a hosted service operated by us.
Continuity	Supplier failure is avoided, but staff turnover, key-person dependency and loss of internal knowledge remain risks.	Your perpetual licence allows the delivered system to continue running and be redeployed without support. Framework patches and upgrades remain dependent on CustomAPIs.
Operations	Your team owns monitoring, deployments, backups, incidents, security maintenance and capacity planning.	Your team can operate the system, or managed operations can be separately scoped. Responsibilities, response coverage and price are agreed explicitly.
Scale and performance	The system can be tailored precisely to the expected workload, but your team must design, test and operate the scaling strategy.	The system starts with a modest AWS footprint and known application and database scaling levers. Performance requirements still need to be established and tested, and higher traffic or resilience requirements increase infrastructure and operating cost.

Services

Implementation services

Teams can adopt the framework themselves. CustomAPIs can also provide architecture, implementation, deployment and operating support where that is useful.

API and platform strategy. What to build, where the boundaries between services fall, and what to build versus buy, before you commit.
Discovery and build. We model your domain with you, then deliver the API as a Handover or Core package.
Deployment. The Core Package is deployed into your own AWS account.
Managed operations. Under a separate agreement, scoped to your scale, resilience requirements and response coverage.
Support. Included with each package for a defined term, then renewable.

We take on a small number of engagements so we can understand each business properly and remain accountable for what we recommend and build. We will tell you if our approach is not the right fit, work with you to get the important decisions right, and remain available to support, evolve or hand over the result as your needs change.

Our process

From first conversation to a running system

Some steps are optional, depending on how settled your architecture is and who will operate the system once it is live.

Free initial consultation
A conversation about your system, what you are trying to build, and an indicative range.
API and platform strategy (optional)
If the architecture decisions are still open, start here: what to build, where the boundaries between services fall, what to build versus buy, and in what order. From AUD $5,000. Read more.
Discovery
Every build starts here. We model your domain together and produce the specification the build is priced against. It is also a decision point: you keep the model and specification, and can stop there if you choose not to proceed. If you continue, discovery is part of the package price rather than an extra.
Build and deliver
The package price, fixed at discovery. How the build itself runs is set out on the Handover and Core package pages.
Operate and support (optional)
Your team operates the system, or we agree a managed-operations arrangement scoped to its scale, resilience requirements and response coverage.

Pricing

Three ways to work with us

Start with strategy before you commit to a build, or go straight to one. Both build packages start from the same core framework — secure, multi-tenant, audited and documented — but differ in scope and how far we take delivery. The Handover Package gives your team a working API to host and run. The Core Package is designed and deployed into your AWS account, with managed operations available under a separate agreement.

API and platform strategy

From AUD $5,000 (ex GST)

For teams about to build. What your platform actually needs — the services, the boundaries between them, build versus buy, and how tenancy and access work across all of it.

Discuss your system Read more

The Handover Package

From AUD $9,999 (ex GST)

For teams with their own platform capability. We build the API; you host and run it.

Discuss your system Read more

The Core Package

From AUD $40k (ex GST)

For teams who want the backend designed, built and deployed into their AWS account, with managed operations available under a separate agreement.

Discuss your system Read more

Comparing the two build packages:

Feature	Handover	Core
Models	up to 5	up to 15
Tenancy	one layer	full relational paths
Identity	adapter to your identity and authorization service	your IdP, or a full user and tenant API
Role & permission endpoints	your system	included
Event publishing	—	one connector
Deployment	artifact handed to you	deployed to your AWS account
Who operates it	your team	your team, or us under a separate managed-operations agreement
Support	3 months	first year, then $6k/yr
Licence	perpetual, for one defined API system	perpetual

Support, licensing, continuity and the four ongoing cost categories are set out in the client guide.

About

A partner you can build on

CustomAPIs aims to help businesses build SaaS and B2B software that works as one coordinated environment, rather than a collection of disconnected systems and bespoke integrations.

The long-term aim is to make B2B software faster and safer to create, easier to evolve, and more capable of supporting the businesses and communities that rely on it.

Sam Tuckey — Founder & Principal Engineer

CustomAPIs is led by Sam Tuckey, an engineer and architect based in Adelaide. Over seven years at H&L Australia (Valsoft Group) he led the move from on-premise legacy systems to multi-tenant cloud SaaS, and architected the Kafka-based event distribution platform that carries orders for more than 1,500 hospitality venues — including integrations with me&u and Uber Eats, peaking at around 70 orders per second in the Christmas trade. He was appointed interim CTO of Easy Employer during its post-acquisition integration into the Valsoft group, and earlier designed StraightSell’s accounting integration framework, still in production today.

The framework is built on the architecture and patterns proven in that work: the permissions, tenancy, auditing and event publishing that every one of those systems needed, built once and properly, instead of rebuilt route by route. Connect with Sam on LinkedIn →

You retain full control of your system, infrastructure and data. Your system is delivered under a software licence that is yours to keep, runs in your own AWS account, and continues to run whether or not you keep a support subscription — with clear handover terms if you ever take it fully in-house. We take on a small number of engagements and stay with them: modelling the domain, delivering the common surface quickly, engineering the parts that are genuinely yours, and operating the result.

Contact

Tell us about your system

Whether you need a new API, want to modernise an existing relational application, or need secure event publishing for integration partners, tell us about the problem.

It helps to know whether the system already has a relational database, roughly how many entities are involved, whether it is multi-tenant, who needs access, and which parts require custom business logic.

Articles

Writing

Where we set out the thinking behind the framework, and how it compares with the other ways of building a multi-tenant API.

Choosing your multi-tenant database architecture is a business decision — database per tenant, schema per tenant or shared tables, chosen from what your customers need and what your team can operate rather than from the database alone.
Supabase vs CustomAPIs for multi-tenant APIs — what row level security enforces, where foreign keys stop carrying tenancy, and what access management actually costs to build.
The multi-tenant API request lifecycle — every stage between the edge and the response, what each one protects, and why rejecting a request early costs less than rejecting it late.

Start with a multi-tenant API framework that's secure from the first request.

Build the product, not the groundwork.

Get the common API surface running early

Custom where it matters

What the Tenant API takes care of

Customer boundaries and controlled access

A trusted record of change

Events that connect your business

Documentation that stays accurate

Works with your identity provider

Scales without changing shape

Call it from the command line, an AI agent or your own code

Built for connected B2B systems

Multi-tenancy that follows your data

Where it fits best

Build the platform foundations yourself — or start from ours?

Implementation services

From first conversation to a running system

Free initial consultation

API and platform strategy (optional)

Discovery

Build and deliver

Operate and support (optional)

Three ways to work with us

API and platform strategy

The Handover Package

The Core Package

A partner you can build on

Tell us about your system

Writing