Integrating
How other systems reach a Meridian site: the read-only content API for headless frontends and builds, outbound webhooks, upstream data sources and scheduled feed imports, the content MCP for AI agents, the member API for a custom portal, and moving content in from WordPress or Sanity.
Meridian talks to other systems through a small set of documented surfaces. Each has its own credentials, limits and contract, and none of them reaches the database or the admin’s internals.
| Surface | Direction | For | Credentials | Bundle |
|---|---|---|---|---|
| Content API | Out (read) | A headless frontend, a static build, an app, a sync job | Content API keys (mrd_pub_, mrd_sec_) | Both |
| Headless sites | Out | Running a public site from a frontend you build: resolve, preview, revalidation, forms and analytics | As above | Both |
| Webhooks | Out (push) | Telling another system that content changed, or that an endpoint ran | An HMAC secret per webhook | Both |
| Sources and importers | In | Reading another service’s JSON on a page or in an endpoint; importing a feed into documents on a schedule | Headers from the environment | Both |
| Content MCP | Both | A person’s AI agent reading and drafting content as that person | OAuth 2.1, or a personal access token | Both |
| Member API | Both | A member portal you build yourself | The member’s session cookie | engine-dmo |
| Migration | In | Moving content, media and old addresses from WordPress, Sanity or another CMS | Command line access to the install | Both |
Principles that hold everywhere
- Every address is configuration. The engine fetches only URLs written in reviewed YAML (
sources.yaml,importers.yaml,webhooks.yaml,site.yaml); nothing a request supplies becomes an outbound address. A redirect is followed only to the same scheme and host. - Secrets are environment variables. Keys, tokens and signing secrets are written
${VAR}and set in the engine’s environment. A literal secret in configuration is a check error. - Errors are structured. The JSON APIs answer failures as RFC 9457 problem details with a stable
code. - Contracts are printable.
engine-dmo api openapi,engine-dmo api schema,engine-dmo api member openapiandengine-dmo mcp tools --jsonprint exactly what this binary serves, so a client can be generated and checked against the version you run.
Reference commands
engine-dmo api openapi --types --project . # the content API's OpenAPI 3.1 document with your types
engine-dmo api schema --site <key> --project . # JSON Schema of each type as delivered
engine-dmo api resolve /some/path --project . # what the content API answers for a path
engine-dmo api keys list --project . # content API keys
engine-dmo webhooks deliveries --project . # the outbound delivery log
engine-dmo mcp tools --project . # what an agent sees Commands that read the install (api resolve, api keys, webhooks, mcp and the imports) need a migrated database at DATABASE_URL. api openapi, api schema and mcp tools read only the project and connect to nothing, though engine.yaml still needs its variables set (any value for DATABASE_URL will do).
Project plugins (experimental)
How to give a declared endpoint logic YAML cannot express with a project plugin: an ordinary program the engine starts, supervises and calls over a Unix socket; plugins.yaml with every option, default and limit, the plugin step, writing one in Go with github.com/wrux/meridian-plugin, protocol version 0 on the wire, building, pinning and failure behaviour.
Content API
The read-only JSON content API at /api/content/v1: turning it on, publishable and secret keys and their capabilities, CORS, every operation and parameter, the document representation and each field type's delivered shape, queries with filters, facets and cursors, caching headers and cache tags, every error code, and the rate limits.