Composer Documentation

Composer is a low-code integration platform. You compose stable, frontend-facing APIs (Interfaces) from backend connectors (Services) — visually, in forms — and Composer executes them. No integration code, no microservices to deploy, no hand-rolled auth/resilience per connection.

New here? Read The Golden Path and Two Rules first (5 minutes), then follow the Quickstart to ship a live API. Use the sidebar to jump to any building block.

The Golden Path

Almost everything you build follows the same five moves. Learn this once and the whole product makes sense.

Create a namespace (project + domain), connect a backend (service), publish a stable API (interface), freeze a snapshot (deploy to an environment), and your apps call it on the runtime. Agents, jobs, and events are variations on this same path.

Control Plane vs. Runtime

Composer is two cooperating services. Knowing which is which prevents most early confusion.

When you click Deploy, the backend writes an immutable snapshot and signals every runtime pod to reload. The runtime then serves from the snapshot — not your live edits.

Two Rules That Explain Everything

Prerequisites & First Login

1. The three services reachable: UI (:3000), backend (:8080), and a runtime (:8081) registered to an environment.
2. An admin account (none is seeded by default — created per environment during setup).
3. Log in to the UI to start building.

Everything in this guide is done in the admin UI. The only API you — and your applications — consume is the interfaces you publish; see Calling Your Interfaces.

Quickstart: Your First Integration

Goal: publish GET /api/retail-banking/v1/accounts/get-balance — a stable API your apps call to read a balance, backed by a core-banking REST endpoint, with zero integration code.

1 · Create a Project & Domain

UI: Projects → New Project (“Retail Banking” → code retail-banking). Open it and add a Domain “Accounts” → accounts.

2 · Set Up an Environment

UI: Environments → Development → Variables. Add CORE_BASE_URL and CORE_TOKEN (mark the token Protected so it’s encrypted at rest and masked in logs). Anything environment-specific or secret becomes a variable referenced as {{env.X}} — dev and prod then differ only by their values.

3 · Build a Service

UI: Service Builder → New Service:

{{env.*}} pulls from the environment; {accountId} resolves from the request (path → query → body → env). Click Test Service to fire a real call and confirm the response shape before building on top of it.

4 · Compose an Interface

UI: Flow Builder (Accounts domain) → New Interface — name “Get Balance” → get-balance, verb GET; declare accountId as a query param; bind the core-get-balance service and map the field in; shape the response into your stable contract ({ "balance": …, "currency": … }).

5 · Deploy

UI: Project → Deploy → Development. Composer freezes a snapshot and the runtime reloads within seconds.

6 · Call It

curl 'https://runtime:8081/api/retail-banking/v1/accounts/get-balance?accountId=10042' \
  -H 'Authorization: Bearer <caller-JWT>'
# → { "balance": 1543.20, "currency": "USD" }

Vocabulary

Snapshots & Deploy

Deploying captures an immutable JSONB snapshot of your project’s configuration into the target environment and publishes a reload signal; every runtime pod reloads its in-memory registries from the database. The runtime always executes the snapshot, never a live entity. Consequences:

• Edits are drafts until you re-deploy — the running API is unaffected.
• Rollback is re-deploying a previous version.
• Promotion is deploying the same project to another environment — identical config, different variables.

Environments & Variables

An environment is a deployment target (Development, Production, a tenant environment). It holds:

• Variables — referenced as {{env.X}}. Mark sensitive ones Protected: they’re encrypted at rest and masked in logs.
• Connections — databases (JDBC), notification providers (SMTP/Twilio), message brokers (Kafka).
• Runtime settings — CORS, timeouts, tool/iteration limits, etc.

Template Grammar

The placeholder grammar wires request data, secrets, and context into service calls and mappings. It is fixed — learn the namespaces, don’t invent syntax. (Full list in the cheat sheet.)

Services

A service is one backend operation — a REST call, a SQL query, a SOAP action, an LLM prompt. It’s the reusable unit an interface binds to. You build it once in the Service Builder, test it against the live backend, and reuse it across interfaces, jobs, and agents.

Anatomy of the builder

The Service Builder is organized into tabs. You’ll touch Details and Main Connector for every service; the rest are optional.

Details tab

A service lives inside a Service Group — that’s where its shared base URL and authentication can come from, so individual services stay lean.

REST connector fields

For a REST service, the Main Connector tab gives you:

Worked example — core-get-balance

The service behind our quickstart interface: a GET to the core-banking sandbox, authenticated with a Bearer token from the environment.

Protocol   REST          Method  GET
Target URL {{env.CORE_BASE_URL}}/accounts/{accountId}/balance
Auth       Bearer  →  {{env.CORE_TOKEN}}
Timeout    30000 ms     Retry   on, 3 attempts, 1000ms backoff

{accountId} is the single-brace shorthand — at execution it resolves from the request (path → query → body → env). For a POST service you’d instead supply a Request Body Template, e.g.:

{
  "fromAccount": "{{request.body.from}}",
  "toAccount":   "{{request.body.to}}",
  "amount":      "{{request.body.amount}}",
  "initiatedBy": "{{session.userId}}"
}

Resilience & audit (free)

Every outbound service runs through a circuit breaker + retry + timeout wrapper (configurable on the Advanced tab and per-environment runtime settings) and is audited automatically — you don’t write any of that. Secrets resolved from {{env.*}} are masked in logs.

Connector Reference

Service Groups

When many services hit the same backend, a Service Group holds their shared base URL and authentication — commonly an OAuth2 machine-to-machine flow where Composer fetches and refreshes the token for you. Attach services to the group; they inherit the connection and credentials instead of repeating them. (Outbound client-cert mTLS, where used, also attaches here.)

What a group holds

Generate, don’t hand-build

From a group you can Generate from DB (introspect a database into services) and Generate Interfaces (scaffold interfaces over the group’s services) — a fast path from a backend to a callable API.

Interfaces

The interface is the contract your apps consume. It lives in a domain, binds one or more services, and shapes the request/response. Built in the Flow Builder.

Anatomy of the Flow Builder

An interface is a small graph: an Interface Request node (the inputs callers send) flows through one or more service nodes and ends at a response. You wire fields by dragging from one node’s output to another’s input — no code.

Interface settings

Variants

One interface contract can have multiple variants — alternate implementations behind the same public shape (a v2 backend, an A/B route, a per-tenant flow). Callers don’t change; the runtime selects the variant.

Synchronous or async

Synchronous by default. An interface can instead return 202 { "executionId": … } and be polled at …/_async/{executionId} — for long-running or bulk work, with no contract change for callers who opt in.

Auth Services Identity

An Auth Service defines how callers are authenticated and how their identity is enriched — without Composer becoming your IdP. A project points its interfaces at an auth service (e.g. an OIDC/Keycloak issuer); the runtime then validates the caller’s JWT (issuer, audience, expiry, signature) before any flow runs, and exposes claims to templates as {{session.*}} / {{token.*}}.

What it validates

On every call the runtime checks the caller’s JWT before any flow runs, and rejects it on failure:

Identity enrichment (optional)

After a token validates, an auth service can run one or more interfaces to fetch extra context (roles, entitlements, customer profile) and persist it on the session — available downstream as {{session.*}}. Field values are never logged. OAuth2 login/refresh/logout flows are mediated by the runtime where needed.

Using claims in a flow

{
  // templated into a service body
  "initiatedBy": "{{session.userId}}",
  "tenant":      "{{token.tenant_id}}"
}

Processors

Processors are ordered steps around a call — configurable on an interface and on each service. They reshape, validate and trace without standing up another backend.

Where they run

Built-ins

When a built-in doesn’t fit, a Custom processor runs sandboxed logic. Combine processors with templates to reshape requests and responses entirely in configuration.

AI Agents Governed

An agent is an LLM-driven assistant whose tools are your interfaces. When the model decides to call a tool, Composer executes the bound interface in-process — so an agent can do anything your interfaces can, behind the same auth and audit.

Two types

Tools are your interfaces

Each tool maps to a deployed interface by code (the tool name is snake_case — the LLM function name). When the model calls a tool, Composer executes the bound interface in-process, behind the same auth, mapping and audit as any other call. An agent can do exactly what its interfaces can — no more.

How a turn runs

1. Input guardrails screen the incoming message (prompt-injection, off-topic, PII).
2. The model responds, optionally emitting tool calls.
3. Tool calls execute as interface calls; results return to the model.
4. Output guardrails screen the reply; a disclosure is appended where configured.
5. The turn is logged with model, token counts, cost, latency and guardrail verdicts.

A blocked turn returns a friendly, category-aware message (not an error), so callers degrade gracefully.

Governance manifest (per agent)

Build in the Agent Builder (provider/model, system prompt, tools, and a Governance tab); deploy with the project. Consumed at POST /api/{projectCode}/v{version}/agents/{agentCode}/chat. The agent dashboards live in Observability.

Scheduled Jobs

A job runs interfaces on a cron schedule instead of on an incoming request — nightly reconciliations, batch exports, polling. A job has ordered steps, each calling an interface, with data passed between them via {{step.data.X}}. Jobs deploy with the project and run on the runtime with distributed locking; every run is audited.

Anatomy

Execution

Jobs deploy with the project and run on the runtime under distributed locking — exactly one pod runs each scheduled execution, so a multi-pod runtime never double-fires. Every run is recorded to job_executions and audited.

Event Subscriptions

The subscribe side of messaging. An Event Subscription consumes a Kafka topic (the broker is an environment connection) and, per message, maps fields with {{message.*}} into an interface request and executes it.

How it works

Bind it to interfaces and deploy it with the project. This turns an event stream into governed interface calls — same auth, mapping and audit — without a bespoke consumer.

Risk Policies & the Risk Gate

An optional decision stage that runs inside interface execution — after authentication, before your flow. It scores the request (your model, built-in rules, or a fraud vendor) and returns one standard verdict:

ALLOWCHALLENGEDENYREVIEW

The four verdicts

Scoring providers

Rollout

Start in shadow (score and log, block nothing), tune against real traffic, then enforce per project/interface. The gate fails closed by default — if scoring is unavailable the request is denied, not waved through. Every decision is recorded as a locked, auditable RiskDecision and streamed to a live dashboard. No contract change for callers.

Observability

Everything you build is observable out of the box: per-interface metrics, a correlation ID through every step, and a masked security-audit trail. These feed:

• Grafana dashboards (provisioned as code) — Runtime, Risk, Agents (tokens/cost/latency, guardrail trips), and a compliance Audit board.
• In-app live trackers — Risk Decisions and Agent Executions, streaming in the admin console.

For agents, full prompts stay in your on-prem audit store; only masked content and metrics leave the box. See the AI Observability & Governance brochure for the full picture.

Deployments & Promotion

Deploy a project to an environment to go live; deploy the same project to another environment to promote (dev → prod) — identical config, environment-specific variables. Each deployment is a versioned, immutable snapshot, so rollback is re-deploying a prior version. Health/readiness probes and audited deployment events round out safe operations.

Template Grammar Cheat Sheet

Calling Your Interfaces

Once deployed, an interface is your API. Your applications call it on the runtime at a predictable, project-scoped URL — this is the entire surface your apps integrate against. (Building and operating Composer itself stays in the admin UI; there’s nothing else for your apps to call.)

URL pattern

{runtime}/api/{projectCode}/v{version}/{domainCode}/{interfaceName}

Authentication

Send the caller’s bearer token: Authorization: Bearer <JWT>. The runtime validates it against the project’s Auth Service before the flow runs, and exposes its claims to templates as {{session.*}}.

Synchronous vs. async

Synchronous interfaces return the result on the same call. Async interfaces return 202 { "executionId": … } immediately; poll the async status endpoint (…/_async/{executionId}) for the result. Same contract either way — no change for callers.

# call a deployed interface
curl 'https://runtime:8081/api/retail-banking/v1/accounts/get-balance?accountId=10042' \
  -H 'Authorization: Bearer <caller-JWT>'

AI agents

Deployed agents are consumed the same way — POST {runtime}/api/{projectCode}/v{version}/agents/{agentCode}/chat — project-scoped and JWT-authenticated. See AI Agents.

Naming & Conventions

Troubleshooting