These cookies are required for the website to function properly. They ensure security, enable basic features like page navigation, and store user session data. You cannot disable these cookies.
The idea
One platform, several clients
What we mean by Headless SaaS
ERP.AI keeps business capabilities in shared backend services instead of locking them inside one screen. Apps, tables, records, views, forms, workflows, reports, documents, pages, roles, and hosting metadata are handled by those services.
The ERP.AI web app uses them. Proto uses them through its ERP.AI actions. Hosted pages and approved integrations use the same service boundary with their own identity and permissions.
Headless does not mean there is no interface. ERP.AI includes a full web product. It means the interface is one client of the platform, not the only place where the work can happen.
The web app, Proto, and approved integrations use the same governed platform services.
ERP.AI product model
Why the shared service layer matters
Reason
1
The web product stays complete
People can build and run apps through tables, forms, dashboards, reports, workflows, documents, custom pages, and administration screens. Programmatic access does not replace that product.
Reason
2
Access rules stay in one place
The gateway resolves identity and tenant context. The service that owns the requested resource checks access before it performs the operation.
Reason
3
Other clients do not need to copy the product
Proto, hosted pages, external apps, and approved integrations can use the platform services without recreating ERP.AI business logic in each client.
Architecture
The services that exist today
How ERP.AI is split
Each service owns a clear part of the product.
Gateway
Authentication, routing, and limits
The gateway accepts a request, resolves the caller and organization context, routes it to the owning service, and applies configured limits.
App Builder
Apps, data, and app features
The App Builder API owns apps, schemas, records, views, forms, workflows, reports, documents, pages, hosting metadata, and audit events. PostgreSQL is the durable source of truth.
Identity
Organizations, users, and permissions
Herbert handles organizations, users, service accounts, keys, OIDC, SCIM, hosted-app sign-in, domains, and portals. The Permission API owns roles, permissions, assignments, and invitations.
Agent + pages
Agent work and hosted output
The Agent API handles conversations, knowledge, app plans, reports, documents, pages, search, and action approvals. The Renderer serves multi-tenant hosted pages and portals.
The web app is part of this system. Headless access adds other governed clients; it does not remove the product interface.
Clients
Use the right surface for the job
People and software use the same platform
The web app is for people who want to work directly with tables, forms, reports, workflows, documents, and settings. Programmatic clients are useful for repeatable work, integrations, hosted experiences, and agent-assisted tasks.
Both paths still need identity, tenant context, resource permissions, validation, and an owning service.
Web product
For direct work
- Tables, records, and multiple views
- Forms and record editing
- Reports and dashboards
- Workflow building and run history
- Documents and custom pages
- Roles, settings, and administration
Programmatic clients
For connected work
- Proto desktop actions
- Hosted pages and portals
- External apps
- Approved integrations
- Scheduled workflows
- Scoped service identities
Access is not automatic. Each caller needs configured credentials and only receives the permissions assigned to it. The platform checks organization, app, table, record, and action boundaries where those controls apply.
The deployed documentation is the contract. It is the source of truth for public locations, available operations, request fields, and response shapes. This page describes the product without inventing technical examples.
What the platform supports
These are product areas present in the ERP.AI codebase today.
01
Data and interfaces
Create apps with typed tables, records, references, formulas, views, forms, layouts, and collaborative updates.
02
Workflows
Build workflows, inspect execution state and node output, see errors, stop runs, and retry supported runs.
03
Reports and documents
Create reports, documents, templates, dashboards, and custom pages on the same app model.
04
Identity and access
Manage organizations, users, roles, permissions, invitations, service accounts, keys, OIDC, and SCIM.
05
Hosted experiences
Serve hosted pages, portals, domains, and external apps through the platform's identity and hosting services.
06
Change and recovery
Use schema branches, commits and merges, snapshots and restore, audit history, workflow run history, trash recovery, and saved page versions where supported.
ERP.AI service ownership
Current service map Gateway identity, routing, limits App Builder apps, schemas, records, workflows, reports, documents, pages Permission API roles, permissions, assignments, invitations Herbert organizations, users, service accounts, hosted-app identity Agent API conversations, knowledge, plans, search, approvals Model proxy model routing and organization usage accounting Renderer hosted pages and portals
Clients already accounted for
Each client uses the service it needs and keeps its own interface and release cycle.
Caller class
Typical caller
Interface contract
Operating note
Human interface
Full product
ERP.AI web app
The main interface for building apps, working with records, configuring workflows, reading reports, and managing access.
Desktop client
ERP.AI actions
Proto
The desktop agent can work with apps, tables, records, views, roles, workflows, reports, pages, documents, branches, previews, keys, hosting, and portals through its ERP.AI actions.
Hosted interface
Renderer
Pages and portals
The renderer serves multi-tenant pages and portals while the platform services keep the underlying data and access rules.
Standalone product
Scoped access
External apps
External apps can be configured in Command Centre with their own authorization, deployment, domains, and audit log.
Automated work
Runs and approvals
Workflows
Workflow execution keeps run state, node output, errors, stop and retry controls, and summaries for supported workflows.
Connected software
Configured identity
Approved integrations
Integrations use configured credentials and the permissions assigned to that caller. They do not bypass the owning service.
One platform, different clients
The product keeps one set of business services while clients choose the interface they need.
DimensionGUI-firstAPI-firstPractical shift
Product use
A person uses the ERP.AI web app to build, review, and operate an app.
Proto, a hosted page, an external app, or an approved integration can perform permitted work through the same platform services.
The interface changes; the owning services and permission checks do not.
Identity
A signed-in user carries organization membership and assigned roles.
A configured software caller uses its own credential and assigned scope.
Each caller is identified and checked instead of borrowing a person's browser session.
Operations
A person starts work from a table, form, report, workflow, or settings page.
A connected client asks the owning service to perform a supported operation.
Business rules stay in the service instead of being copied into every client.
Request path
What happens when a client asks for work
A request has an owner
ERP.AI does not treat every capability as one generic endpoint. A request moves through the gateway to the service that owns the resource.
01
Resolve the caller
The gateway resolves identity and organization context from the configured sign-in or service credential.
02
Check the requested resource
The owning service checks access to the app and the requested table, record, workflow, page, role, or other resource.
03
Perform the operation
The service validates the request, applies its business rules, and reads or writes the authoritative store.
04
Keep the applicable history
Audit, version, workflow-run, snapshot, or deployment records are written where that product surface supports them.
One platform service owns each operation.Every client goes through that boundary.
ERP.AI request model
What the shared services provide
The value is practical: clients can reuse the product's data model and controls.
-
01
One app model
Tables, columns, records, views, forms, workflows, reports, documents, and pages remain part of the same app.
-
02
Named callers
People and configured software clients use identities the platform can check and attribute.
-
03
Scoped access
Organization, app, role, resource, and action checks stay with the services that own them.
-
04
Durable data
PostgreSQL is the authoritative store; an accelerated record path falls back to PostgreSQL when needed.
-
05
Shared business rules
Validation and app behavior live in the platform rather than being reimplemented in each client.
-
06
Workflow evidence
Supported workflows keep execution state, output, errors, stop and retry controls, and summaries.
-
07
Change records
Branches, commits, merges, snapshots, audit events, page versions, and deployment history cover the changes they own.
-
08
Hosted output
Pages, portals, external apps, domains, and their identity settings can be managed as product surfaces.
-
09
Separate release cycles
The web app, Proto, hosted output, and integrations can evolve without moving business ownership out of the platform services.
The definition
Plainly stated
A full product with a reusable service layer
That is what Headless SaaS means here. ERP.AI has a web interface, and its business capabilities also sit behind services used by other approved clients.
It does not mean every internal operation is public. It does not mean every client has the same access. It means the platform can support more than one interface without duplicating the core product.
Keep the interface.Keep the business logic reusable.
ERP.AI
Headless SaaS
Shared platform services
Use the product through the right client.
Build in the ERP.AI web app, work through Proto, or connect an approved client with its own scoped identity.