Skip to main content

API Reference — Overview

Every Stack9 capability is reachable over HTTP. There is no proprietary protocol and no vendor-specific SDK requirement: the surface is REST, described with OpenAPI 3.0, and secured with API keys or OpenID Connect.

That matters beyond convenience. Because the whole surface is standards-based, your content and data stay accessible and portable regardless of future platform decisions, and integrating partners don't need Stack9-specific tooling.

The three API surfaces​

SurfaceWhat it coversStart here
Core REST APIFull CRUD for every entity you define on your own instance, with filtering, pagination, sorting and relationship loadingREST API reference
Stack9 Experience (DXP) APIContent and pages, forms, email and templates, marketing campaigns, subscribers and audiences, journeys, marketing events, file manager, business units, reportsDXP API reference
Instance MCPThe queries and automations you choose to expose as Model Context Protocol tools, so an MCP-capable AI agent can read data and trigger workflows under your existing permissionsMCP endpoint reference

Core REST API​

Define an entity and Stack9 generates its data structures, its REST resources and a default set of screens. Your custom, instance-specific data structures are therefore exposed through the same open standard as the rest of the platform — see the REST API reference for endpoint shapes, query parameters and relationship loading.

Stack9 Experience API​

The DXP layer exposes 100+ documented REST endpoints at https://apis.app.stack9.co/api, authenticated with an X-API-Key header. The DXP API reference documents each resource area individually, and the live specification is published at apis.app.stack9.co.

Because Core and Experience share one backend API layer, one data model and one permission model, content, customer data, entities and permissions are read and written through a common layer rather than synced between disconnected systems.

Authorisation​

  • API keys for service-to-service and integration use.
  • OpenID Connect where a request acts on behalf of a user.

Authorisation is enforced inside the request, not at the edge. Entity access is checked against real read privileges, automation calls against automation permissions, and row-level security scopes results to the records that user is entitled to see. Anything not explicitly allowed is denied.

There is no direct database access path that bypasses these controls — all data access is mediated through the application layer.

Next​