#Configure an inbound action

An inbound action describes what an external system sends and, in webhook mode, how Chester registers for it — including extra registration steps, a cursor that tracks the last change, and a delta query that fetches the changes page by page.

An inbound action belongs to a webhook adapter. A message start event or a message catch event picks it.

#From notification to process data

sequenceDiagram
  participant X as Provider
  participant C as Chester
  participant P as Process
  X->>C: Notification "something changed" (cursor 1042)
  C->>C: Cursor seen before? → skip
  C->>X: Delta query from the stored cursor (1037), page by page
  X-->>C: The changes, and the new cursor
  C->>C: Store cursor 1042
  C->>P: Start or continue: rawResponse, deltaResponse, deltaTransformation

#What the external system sends

On the action's Schema tab:

• Request Body Schema — the shape of the incoming body. Later steps can pick its fields. See Schemas and transformations.
• Transformationen — decode fields of the body before the process sees them. Webhook mode only; a static URL ignores them.

The Incoming method and Endpoint path document what the provider sends. ⚠️ They do not change the address Chester receives on.

#Register the webhook

Webhook mode only. In Registration, set the Method and Registration path, and the Registration Payload Schema — the body Chester sends. Its default values are filled in, and the element can override every field not marked read-only.

Placeholders the body can use:

⚠️ The list on the page names only {signatureSecret}, {expirationDateTime} and {clientState}.

⚠️ Saving the action removes the read-only marks from the payload schema.

#Extra steps before and after

Some providers need more than one call:

• Pre-Steps run before the registration — for example creating a topic the registration then names. Their Response Mapping makes values available to the next steps.
• Further steps run after it, and can use its response.

Each step has a Label, an optional Base URL — another host if needed — a Method, a Path, a Payload Schema, a Response ID Path, how it logs in, and how it is removed again (Deregistration). If a step fails, the steps before it are rolled back.

How a step logs in:

• Inherit (the default) — the adapter's own login, but only if the step goes to the same address as the registration (same scheme, host and port). A step with a Base URL on another host fails the registration instead of handing the adapter's credentials over. Set it to None if that host needs no login.
• API key from an environment variable — only REGISTRY_API_KEY, and only towards the ProcessHub Registry. Any other variable fails the registration; put the key on a credential instead.
• None — no login.

⚠️ A failed primary registration does not roll back the pre-steps.

#Track changes with a cursor

Providers such as Gmail only send "something changed, you are now at position 1042". With Cursor-Management Chester keeps that position per registration:

• Initialer Cursor — where to start: a fixed value, or a value from a registration response.
• Cursor path (notification) — where the notification carries the position. Without Cursor field optional, a notification without it is skipped.
• Cursor-Idempotenz — skip notifications whose position was seen before: exactly equal, or numerically not higher.

⚠️ With pre-steps configured, Step 1 in Initialer Cursor reads the first pre-step, not the first further step.

#Fetch the changes with a delta query

With Delta-Query aktivieren, Chester answers every notification by asking the provider for the changes since the stored position:

• Method, Path, Delta-Query Parameter and Request Body. Their values are set on the message event, and can use only _inbound.cursor.previous — the stored position.
• New cursor (response path) — where the answer carries the new position.
• Delta-Query Response Schema — the shape of the answer, for the variable list.
• Pagination — Next page token (response path), Page-Token-Parameter and Max Pages (10 unless set).
• Delta-Transform aktivieren — the message event can then reduce the answer with an expression, for example to the list of new messages. It runs in the same sandbox as every other expression: it sees only deltaResponse and, by default, has 10 seconds and at most 1 MB of answer to work on. Beyond that the notification is not processed.

The process receives, under the event's id:

An empty answer, or an empty transform result, starts or continues nothing. One notification starts one instance, however many changes it brings.

⚠️ Leave New cursor (response path) empty, or point it to a field that is missing, and the position never moves on.

⚠️ _inbound.cursor.current holds the same value as previous inside the delta query.

⚠️ The Page-Token-Parameter must also be declared among the delta query's parameters, or it is not sent.

⚠️ At Max Pages Chester stops without a warning; changes on later pages may be missed.

⚠️ A field name with a dot in it — such as @odata.nextLink — cannot be addressed by a path.

❌ Paging by a full next-page URL, and one instance per change, are not possible.

If the delta query fails with a server error or 429, it is retried three times with a growing wait; other failures are not retried.

#Continue waiting processes — Correlation Value Path

Static URL only. The field of the body whose value is compared with a waiting message catch event's Correlation ID — for example event.thread_ts. Only a plain path of names; no [0].

#Drop duplicate deliveries — Idempotenz

A Key Expression over payload, headers and query — the body as sent, before transformations — for example headers["x-request-id"]. A second delivery with the same key within the TTL (600 seconds unless set) is dropped. If the key cannot be worked out, the delivery is let through.

⚠️ Wiederholungsversuche, Delay (ms) and the active / deprecated switch have no effect on inbound actions.

⚠️ Most section titles on this page are German, whatever the language of the screen: Cursor-Management, Idempotenz, Transformationen, Metadaten.