Process Signals¶

Use a process signal to notify a workflow from an external system. Call the signal URL with GET or POST to trigger its configured event. POST can optionally include XML or plain text data. No API key or user login is required.

Use Trigger when the caller needs event results or case/test-mode options.

Configure a Signal¶

A tenant administrator with permission to edit the domain configures signals in Edit Domain, in the Process Signals tab beside API Keys.

1. Add a signal and copy its generated Signal ID.
2. Set Event Name to the event consumed by the target workflow.
3. Set Suppression Duration, enable the signal, and save the domain.

Send a Signal¶

Use the target tenant's hostname and replace <signal-guid> with the configured Signal ID:

1

GET https://mydomain.emakin.com/rest/v1/signals/<signal-guid>

POST without a body also sends a signal:

1

curl --request POST "${EMAKIN_SIGNAL_URL}"

Set EMAKIN_SIGNAL_URL to the complete private signal URL. No authentication header or query parameters are needed. Query parameters are not accepted. HEAD and OPTIONS do not trigger an event.

Include Optional Data¶

Send data in the POST request body as UTF-8 text.

XML¶

1
2
3
4

curl --request POST \
  --header "Content-Type: application/xml" \
  --data-binary '<Report><Value>42</Value></Report>' \
  "${EMAKIN_SIGNAL_URL}"

A valid XML document is passed to the event with its original root element.

Plain Text¶

1
2
3
4

curl --request POST \
  --header "Content-Type: text/plain; charset=utf-8" \
  --data-binary 'Report submitted' \
  "${EMAKIN_SIGNAL_URL}"

Content that cannot be parsed as XML is passed as the text value of a <Data> element. For example, Report submitted becomes <Data>Report submitted</Data>. XML special characters are escaped while preserving the text value. JSON, malformed XML, and XML containing DTD declarations are treated as plain text.

Data is optional. An empty POST body or a GET request supplies <Data />. GET request bodies are ignored.

Repeated Signals¶

Suppression Duration prevents repeated calls from triggering the same signal too frequently. With the default of 5 seconds, the first accepted call triggers the event; further calls for that signal within those 5 seconds are ignored. A later call can trigger the event again after the interval expires.

The first accepted request supplies the data. Suppressed calls do not replace that data and are not replayed later. Separate signals have independent suppression intervals. Choose an interval that also allows legitimate new notifications through; a new notification within the interval is ignored just like a duplicate.

Frequent calls from the same source IP can also be rate limited. Rate-limited calls receive the same empty response.

Response¶

1
2

HTTP/1.1 204 No Content
Cache-Control: no-store

The response is returned without waiting for event completion. The same empty 204 response is returned for accepted, unknown, disabled, suppressed, rate-limited, or failed signal requests. It does not confirm that the event ran. Connection, proxy, and other request handling errors may produce different responses.

Check the resulting workflow behavior to verify an integration. If the expected action does not occur, check the target tenant, signal ID, enabled state, event listeners, and suppression interval. Ask an administrator to review the logs when needed. Do not retry solely because the endpoint returned no event result.

Related Pages¶

• REST Services
• Trigger
• Event Listener Module