An API endpoint is a single REST operation inside a collection — a URL path plus the HTTP methods it answers — backed by an automation, AI model, external API, or event stream.
Overview
Every operation you want to expose becomes an endpoint. An endpoint lives inside a collection (which sets the base path), defines its own request contract and response shapes, and can carry its own policies, timeout, caching, and logging. When a caller hits the endpoint's URL with an allowed method, the platform runs the backing resource and returns its result as the response.
Creating an Endpoint
Inside a collection, add an endpoint and configure:
Name — a display label for the operation.
Path — the URL segment under the collection's base path (for example /{"{id}"} or /search). Must be unique within the collection; can contain path variables like {"{id}"}.
Resource type and Resource — what backs the endpoint (see Resource Types below) and which specific automation, model, API, or stream it points to. Optionally pin it to a specific version of that resource.
HTTP methods — the verbs the endpoint answers (one or more of GET, PUT, POST, PATCH, DELETE, or HEAD).
Endpoint type — REST (JSON) or SOAP (XML).
Active — whether the endpoint is live and accepting calls.
Resource Types
An endpoint fronts one of five resource types, each invoked differently:
Resource Type | Invocation Behaviour | When to Use |
|---|---|---|
Callable | Runs a synchronous automation and waits for the result. | Request/response operations where the caller needs the output. |
Webhook | Accepts the call immediately; the automation runs in the background. | Fire-and-forget triggers where the caller does not need an immediate result. |
LLM Model | Passes the payload to a large language model and returns its response. | Exposing AI models as callable APIs. |
External API | Proxies the request to an upstream third-party API. | Adding your own auth, rate limits, and monitoring in front of an API you do not own. |
Event Stream | Publishes the request payload as an event to a topic. | Accepting events from external producers. |
HTTP Methods
An endpoint declares which HTTP methods it answers: GET, PUT, POST, PATCH, DELETE, or HEAD. Only these fixed methods are supported — you must specify at least one. A caller using a method the endpoint does not list receives 405 Method Not Allowed. One endpoint can cover several methods, or you can split a path across endpoints — whichever maps more cleanly to the operations you are exposing.
Endpoint Type
Each endpoint has an endpoint type of REST or SOAP. REST endpoints exchange JSON (the common case); SOAP endpoints carry a SOAP version and target namespace and exchange XML. Choose REST unless the consuming application specifically requires SOAP. The content type of the request and response follows from this choice.
Activating and Deactivating Endpoints
The Active flag controls whether an endpoint is live. An active endpoint answers calls; an inactive one rejects all calls with 403 Forbidden, even if auth and routing would otherwise pass. Use the toggle to take an endpoint offline temporarily — for maintenance or before you are ready to publish — without deleting its configuration.
Advanced Settings
Advanced Settings give you fine-grained control over an endpoint's performance, resilience, and rollout: timeout, response caching, fallback responses, error apping, canary deployments, and per-endpoint logging. Once an endpoint is live, these settings let you tune it without changing the backing automation. Timeout and caching address performance; fallback and error mapping address resilience; canary deployment addresses safe rollout; and logging controls what is captured for debugging. Configure the settings that matter for each endpoint individually — production endpoints with high traffic or strict SLAs need more attention here than internal or low-traffic ones.
TTL (time-to-live) — how long a cached entry is valid before it expires and the next call runs the resource again.
The cache key is built from the request (path, parameters, and body), so only matching requests share a cached entry.
A response served from cache carries an X-Cache header so callers can tell.
The fallback status code, body, and headers.
Locale-based fallbacks — a different message per Accept-Language header, so international callers see an appropriate response.
Retries — the endpoint can retry a failed call a configurable number of times before triggering the fallback.
Split traffic by percentage (for example, 10% to the new version, 90% to the current).
Or split by rule — route specific callers or request patterns to the new version.
Name endpoints after the operation they perform, not the resource alone — "Get order by ID" is clearer than "Order".
Use Callable for synchronous operations where the caller needs the result; use Webhook when the caller only needs confirmation the request was accepted.
Pin the backing resource to a specific version for stability on production endpoints; leave it unpinned only if you want the endpoint to pick up new deployments automatically.
One endpoint can cover multiple HTTP methods — only split them into separate endpoints when the request or response contract differs between methods.
Do not leave endpoints inactive for long periods — deactivate before you are ready, then activate; delete endpoints you know you will not publish.
Always configure a fallback response on customer-facing endpoints — a momentary automation failure should not surface a raw 500.
Set the timeout from the backing automation's typical runtime, with enough headroom for normal variation; a timeout too close to the average causes unnecessary failures.
Enable caching only for endpoints whose output is stable between calls; check the cache hit rate in the Insights dashboard to confirm it is working.
Use canary for any change that modifies the automation's output schema or behaviour — roll back in seconds if callers report issues.
Raise per-endpoint logging temporarily when debugging; lower it again once resolved to avoid storing unnecessary run data.
Timeout
Set a timeout — the maximum time the backing resource may take — by choosing a value and a unit (milliseconds, seconds, or minutes). If the resource does not finish within that time, the platform abandons the call and the caller receives 408 Request Timeout. Set the value generously enough for normal work (especially for automations that do heavy processing) but low enough that a stuck call fails fast rather than tying up the caller indefinitely.
Response Caching
Enable response caching to serve repeated identical calls from a stored response instead of invoking the backing resource every time. Configure:
Use caching for endpoints whose results do not change on every call — reference data, expensive computations — to cut latency and reduce load. Avoid it where every call must be fresh.
Fallback Response
A fallback response is a fixed response the endpoint returns when the backing resource fails, so callers receive a controlled answer instead of a raw error. Configure:
A well-configured fallback makes a published API dependable even when the underlying automation has a momentary failure.
Error Mapping
An endpoint can carry error-code mappings that translate internal error codes into caller-friendly messages. Instead of surfacing a raw or cryptic error, the endpoint returns the message you mapped for that code — for example "Order not found" for a specific internal error. This keeps internal details out of the API response and gives consumers actionable errors they can display or handle.
Canary Deployment
Use canary deployment to roll out a change to an endpoint gradually — sending a portion of traffic to a new version while the rest stays on the current one:
Increase the share as confidence grows, or roll back instantly if something is wrong. Use canary for risky changes to a live endpoint. For a clean breaking change, version the collection instead so callers opt in explicitly.
Per-Endpoint Logging
An endpoint can set its own logging level — controlling run, node (step), and variable logging for its backing automation — overriding the collection's defaults. Higher logging captures more detail and makes debugging easier, but stores more data. Raise logging on an endpoint you are actively troubleshooting and keep it lean on stable, high-traffic endpoints. These settings flow into the backing automation's execution records.