Skip to Content
IntegrationsHTTP and SOAP

HTTP and SOAP

REST reception

POST /api/{interface-code}/{definition-code}

Accepts application/json, application/xml and text/plain. Authentication uses the application’s API Token, in any of these forms:

x-api-token: <token>
Authorization: Bearer <token>
Authorization: Basic <base64 with the token in the password position>

Response:

{
  "id_message": "message-uuid",
  "message_type": "ASYNC",
  "return_message": "Message received and queued",
  "hasError": false
}

If the Definition is SINCRONA, the response only comes back after delivery to the destination — and carries its result.

Synchronous Delivery response

In a SINCRONA Delivery, return_message is always a status text — and what the destination answered comes separately, in response_payload:

{
  "id_message": "4f055330-1c87-4423-89ee-1513d66bc6f2",
  "message_type": "SYNC",
  "return_message": "Message delivered successfully",
  "hasError": false,
  "response_payload": { "MessageName": "AnyToMES", "id": 101 }
}
  • JSON comes back as JSON; XML or text come back as a string, with no wrapper — the same format as the Collector’s collected_payload.
  • Destination answered empty (an HTTP 204, for example): the field is absent.
  • On error (hasError: true), return_message carries the Business Error description or the delivery failure, and response_payload carries the body the destination returned, if any.
  • In SOAP, the same content goes in the optional <response_payload> element, as text.

Until September 2026 the destination response came raw inside return_message.

Input decoding

When the client cannot send the final format, the Definition can decode it first: BASE64, XML_UNESCAPED, URL_ENCODED, HEX, CHARSET_LATIN1, HTML_ENTITIES.

SOAP reception

Definitions with Enable WebService (WSDL) turned on get a SOAP endpoint with a dynamically generated WSDL:

GET  /api/ws/{interface}/{definition}?wsdl
POST /api/ws/{interface}/{definition}

Authentication can come through WS-Security UsernameToken in the envelope instead of the header.

A Collector with Input Parameters has the same switch, and with it the Dynamic Collector API also answers in SOAP, through the ExecutarColeta operation:

GET  /api/ws/collect/{interface}/{collector}?wsdl
POST /api/ws/collect/{interface}/{collector}

Each Input Parameter becomes an element of the envelope, and the WS-Security of this operation also accepts the login and password of an Inbound Credential. See Dynamic Collector API.

HTTP collection

Types HTTP_GET and HTTP_POST: CMS calls an external endpoint on a schedule and forwards the response to the configured destination interfaces. With Input Parameters, the Collector runs on demand instead — by whoever calls the Dynamic Collector API, by a Trigger or by an AI agent —, and the parameters go into the call’s URL and body.

Typical setup:

  • URL and method
  • Credential for authentication (basic, bearer, header)
  • Transformer to convert the response into the destination format
  • Schedule (cron or interval) under Schedulers

To consume a paginated API, or one that requires building the URL from another value, solve it in the Transformer or chain collectors — CMS does not paginate automatically.

HTTP delivery

Types HTTP_POST, HTTP_PUT, HTTP_PATCH, HTTP_DELETE, each with its own timeout, retries and backoff per Definition. The destination response is stored in the message history and evaluated by Business Error rules.

SOAP delivery

Type HTTP_SOAP: sends the assembled envelope to the destination endpoint, with a WS-Security credential when configured.

OverviewMQTT