Configuring REST Service Endpoints
REST service endpoints in Adeptia let you expose your integration workflows as callable web services, so that external applications and partners can send data to and receive data from your processes over standard HTTP.
What REST endpoints let you do
When you publish an integration as a REST endpoint, external callers can invoke it by sending an HTTP request. Adeptia receives the request, routes it to the correct workflow, executes the integration logic, and returns a response. This makes it straightforward to connect external systems, trading partners, or custom applications to your Adeptia-managed processes without requiring those callers to understand the internal structure of your workflows.
REST endpoints support both synchronous and asynchronous execution. In asynchronous mode, Adeptia accepts the request immediately and processes it in the background, returning a success acknowledgment to the caller right away.
How endpoints fit into your integrations
Each REST endpoint is associated with a specific workflow or process template. When a request arrives at the endpoint, Adeptia matches it to the correct workflow and passes along the request data, including any query parameters, headers, and body content, as context that the workflow can act on.
Endpoints can be configured to operate in different publish modes:
| Publish mode | How it works |
|---|---|
| Webhook | The endpoint accepts incoming data and routes it to a workflow based on a template mapping. Supports both file attachments and body payloads. |
What you provide when configuring an endpoint
When setting up a REST endpoint, you define how the endpoint behaves and what it accepts:
| What you configure | Purpose |
|---|---|
| HTTP method support | Which HTTP methods (such as GET, POST, or DELETE) the endpoint responds to |
| Resource path | The path segment that identifies this endpoint to callers |
| API version | An optional version label that is included in the endpoint path and made available to the workflow |
| Request encoding | The character encoding used to read incoming request data |
| Response content type | The media type returned to the caller on success |
| Fault content type | The media type returned to the caller when an error occurs |
| Response status codes | The HTTP status codes sent back for successful responses and for faults |
| Response headers | Custom headers to include in the response, which can be populated from workflow output |
| Security policy | Controls how callers authenticate to the endpoint, including API key-based access |
| Synchronous or asynchronous mode | Whether the caller waits for a result or receives an immediate acknowledgment |
Sending data to an endpoint
Callers can send data to a REST endpoint in several ways. Adeptia handles plain request bodies, multipart form data with file attachments, and requests with no body (such as GET or DELETE requests). For multipart requests, Adeptia reads each part and makes the content and metadata available to the workflow. Query parameters and request headers are also captured and passed into the workflow context automatically.
When a request includes file attachments, Adeptia stores the uploaded files and makes their locations available to the workflow for further processing.
Receiving a response
After the workflow runs, Adeptia assembles the response from the workflow's output. If the workflow produces a fault or no output at all, Adeptia returns an appropriate error status and message to the caller. When the response includes file attachments, Adeptia can return them as a multipart response alongside any text body content.
Response headers can be set to static values or populated dynamically from values produced by the workflow at runtime.