Can the same Callable be invoked both via API and from another automation?

Yes. A Callable is not limited to one invocation path. The same Callable can be called from automation nodes and from external systems via API, simultaneously if needed. Each invocation runs independently.

How does the external caller authenticate?

The caller authenticates using the platform's standard API authentication — typically an API key or token passed in the request headers. The Callable endpoint enforces authentication and will reject unauthenticated requests.

What does an asynchronous API response look like?

The response is a simple acknowledgement confirming the Callable run was accepted and started. It does not include the Callable's outputs. If the caller needs the output later, it must use a separate mechanism (such as a webhook callback or a polling endpoint) to retrieve it.

Unify Automations › Building Automations › Setup Triggers › Callable — Via API

Callable — Via API

3 mins read

A Callable exposed via API becomes an HTTP endpoint that any external system can invoke. The caller sends the Callable's defined inputs in the request, the automation runs its steps, and the caller either waits for the result (synchronous) or receives an immediate acknowledgement and lets the run complete independently (asynchronous). Use this pattern to make automation logic available to scripts, external services, or third-party tools outside the platform.

Overview

When a Callable is exposed as an API endpoint, external systems interact with it using standard HTTP. The Callable's input schema defines what the caller must send; the Callable's output schema defines what the caller receives back. The platform handles authentication, routing, and execution — the external caller simply makes an HTTP request and reads the response.

Exposing a Callable as an API

To make a Callable available via API, configure it as an API-accessible Callable in the automation builder. The platform generates an endpoint the caller uses to invoke it. The Callable's defined inputs become the request body fields the caller must supply; the Callable's defined outputs become the fields returned in the response.

Any system that can make an authenticated HTTP request can invoke the Callable — scripts, backend services, third-party tools, or other platforms that need to run automation logic on demand.

Synchronous Invocation

In synchronous mode, the HTTP request waits for the Callable to complete and returns the Callable's full outputs in the response body. The caller receives the result directly — no polling or callback needed.

Use synchronous invocation when:

The external system needs the automation's output values before it can proceed.
The result is small and the automation completes quickly enough to fit within the caller's HTTP timeout.
You want failures to surface as HTTP error responses the caller can handle.

Mind the timeout: Synchronous API calls hold the HTTP connection open until the Callable finishes. If the automation is slow, the connection may time out before a response is sent. Use asynchronous mode for long-running work.

Asynchronous Invocation

In asynchronous mode, the HTTP request returns immediately with a simple acknowledgement — confirming the Callable was accepted and started — without waiting for it to complete. The Callable then runs independently; its outputs are not returned to the original caller.

Use asynchronous invocation when:

The automation is long-running and would exceed an HTTP timeout in synchronous mode.
The external system only needs to trigger the work, not receive a result.
You want the caller to remain unaffected if the Callable fails.

Run Context

A Callable invoked via API can run in the calling user's security context when configured to do so. The platform identifies the user from the API request's authentication credentials and runs the Callable's steps with that user's permissions applied. This keeps access-control checks accurate when the Callable reads or writes data scoped per user.

Without user context, the Callable runs as a generic service identity and behaves identically regardless of which authenticated user made the request.

Notes

Keep the following in mind when invoking a Callable via API.

The Callable's input schema defines the request body. External callers must supply all required fields — missing or mistyped inputs are rejected before the run begins.
Use synchronous mode when the caller needs the output values and the automation completes quickly; use asynchronous mode for long-running automations or fire-and-forget triggers.
Synchronous calls hold the HTTP connection open until the Callable finishes. Long automations risk connection timeouts — prefer asynchronous mode in those cases.
Enable user context when the Callable accesses data whose permissions are scoped to the authenticated API user.
Authenticate every API call using the platform's standard authentication mechanism. The Callable endpoint is not publicly accessible without credentials.

Test the API endpoint with a representative payload before connecting external systems. Confirm that inputs map correctly, outputs match what the caller expects, and error responses are handled gracefully on the caller side.