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.
Notes
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.