chesterdocs

#Systems and adapters

Adapters connect a process to an external system over HTTP, webhooks, GraphQL, email or an LLM provider.

Everything a process does outside Chester goes through an adapter. You define them once under Systems, and every process can then use them without repeating the connection details.

#What you can do here

  • Describe an external service, and how Chester connects to it.
  • Define the individual operations a process can call — create a ticket, fetch an invoice.
  • Point the same operation at a different server per environment.
  • Let an external system start a process, by receiving a webhook.
  • Connect the language model an agent runs on — see Connect an LLM provider.

#How it fits together

The System landscape screen in Chester, listing the connected systems. Each row shows one system — SendGrid Email, Stripe Billing, Salesforce CRM and Northwind ERP — with a short description, a status such as "Active", and its software type. The row carries the system's name and status only: no address and no password appear in the list.

Three levels, and keeping them apart is what lets one definition serve every process: a system is the service itself, an adapter is one way of connecting to it, and an action is a single operation that adapter can perform.

A system is the service itself — a name, a logo, some tags. It holds no address and no password. An adapter is one way of connecting to that system, and a system can have more than one. An action is a single operation the adapter can perform.

Read Systems, adapters and actions for how to create each one. For the actions themselves: HTTP actions, GraphQL actions, inbound actions and schemas and transformations.

#Where the address and the password live

For HTTP, GraphQL and webhook adapters: not on the adapter. A system has environments, and each environment carries the base URL and the credential for that server — production, test and development can be the same adapter pointed at three places.

The exceptions: an email adapter keeps its mail server and login on the adapter, and a static-URL webhook keeps its API key and signature secret there.

Which environment a step uses is chosen while modelling and frozen into the deployment, so it is part of the process rather than something selected when an instance starts. See Environments and credentials.

#Directions

An adapter has a direction, which follows from its type — you pick the type, not the direction:

Direction Who calls whom Typical use
Outbound Chester calls the external system Create a record, fetch data
Inbound The external system calls Chester A webhook starts or continues a process
Signal An event without a direct caller Broadcast to waiting processes. ⚠️ Cannot be created in the Designer — see signal events

The types: HTTP / REST and GraphQL are outbound, HTTP Inbound / Webhook is inbound, E-Mail (SMTP) and LLM provider are outbound without actions.