> For the complete documentation index, see [llms.txt](https://docs.autommate.com/userguide/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.autommate.com/userguide/integrations-and-api/webhooks-api-rules-and-responses.md). # Webhooks, API rules, and responses Use an incoming webhook or API trigger when another system needs to start an automation. Define both sides of the interaction: the request you accept and the result you return. ### Define the request Record the intended caller, HTTP method, endpoint, authentication, required fields, and content type. Use the endpoint displayed in the intended automation version. Keep test and operational callers distinguishable in your configuration and records. Incoming webhook rules can inspect request **header**, **query**, or **body** parameters. The documented rule fields are: | Field | Purpose | | -------------- | -------------------------------------------------------------------- | | Rule Name | Identifies the rule | | Description | Explains its purpose | | Parameter Type | Selects header, query, or body | | Key | Identifies the parameter to inspect | | Operation | Compares the parameter, for example equals, contains, or starts with | | Target Value | Supplies the comparison value | Associate the relevant rule set with the intended flow. Treat filtering and authentication as separate parts of the design: matching a business field does not establish who sent a request. ### Service Automation webhook contract For a **Service Automation deployment**, the service webhook accepts **POST**. Use the generated development URL with `&dev` to target draft; without that flag, it targets live/production. A browser GET is not a valid trigger test. This routing rule is specific to the service deployment entry. It does not replace the request and response contract of a separate Hyperflow API/webhook trigger. Confirm the body and authentication shown for the actual deployment, and correlate its invocation with a Service Case before reporting completion. Example: a no-input Enterprise service accepts POST with {} and returns HTTP 200 with {"status":true,"message":"Flow triggered"}. Use the input body required by your service. This acknowledgement is separate from completion; find the matching Service Case and inspect its result. ### Check the received data Inspect triggerParam and triggerHeader with a controlled request. Repeated query keys are represented as an Array and a single occurrence as a String; handle the representation your caller sends. For example, do not assume a parameter has one value if the caller may send it twice. Decide whether to reject multiple values or handle them explicitly. ### Define the response Response delivery depends on the trigger and caller. For a response-capable API flow, the documented **Stop Action** supports **No Data**, **Application/Json**, **Application/XML**, **Text/Plain**, **Text/XML**, and **Text/HTML**. Verify the selected trigger's actual response behavior before promising a synchronous result. An API-triggered MCP run can return flow output; a webhook-triggered run starts work without returning an operation ID. Check execution history when the response only acknowledges the request. See [run an existing Hyperflow through MCP](/userguide/mcp-and-ai-reference/run-an-existing-autom-through-mcp.md). Return only the information needed by the caller. A useful response contract states whether the request completed, what record or result it produced, and how a failure is represented. Choose actual fields in your implementation; do not assume the platform supplies a standard business-result schema. Use **Stop & Response** in the error configuration when an action failure must stop the flow and return an error response. Configure the status, message, response type, and body consistently with the caller's expectations. ### Test the whole interaction Check one valid request, one missing required value, one rejected credential, and one controlled downstream failure. Inspect both the caller's response and the automation execution record. Agree how the caller handles a timeout or an uncertain result. Check whether the operation already occurred before retrying a write; a missing response does not prove that nothing happened. Record a stable business identifier where the target system supports one so that repeated requests can be reconciled. ### Worked design: accept one request source and inspect the caller result Use an isolated API/webhook Hyperflow that performs only local text processing. The following body is a sample contract to implement, not a pre-existing endpoint or an already-run test: {"source":"docs-demo","request\_id":"REQ-DEMO-001"}. 1\. Configure the trigger on the intended test version and copy its generated endpoint. Record its HTTP method, authentication and content type from that configuration. 2\. Create a rule associated only with the test flow. Select the request Body parameter, set Key to source, and choose the installed equality operation with Target Value docs-demo. Keep authentication configured separately.
Current Add Rule wizard at the Rule step, after Details and before Add Hyper Flow. Body and is equal are selected; Key, Target Value and Status remain blank. This was not saved or used to trigger a flow.

Current Add Rule wizard at the Rule step, after Details and before Add Hyper Flow. Body and is equal are selected; Key, Target Value and Status remain blank. This was not saved or used to trigger a flow.

For the sample contract, use Params = Body, Key = source, Operator = is equal and Target Value = docs-demo. The current wizard also requires Status; agree its intended value with the caller contract and verify the actual response during the controlled test. The form alone does not prove how matching or nonmatching requests are returned. Add the completed condition, then continue to Add Hyper Flow and choose only the intended test flow. Keep the generated endpoint and its authentication details private. The configuration inspection did not send a webhook request or establish runtime rule behavior. 3\. Use the trigger’s actual received data to map request\_id into a local String result. Inspect triggerParam rather than guessing a nested JSON path. 4\. Send one approved request matching the sample body. Save the caller’s HTTP status/body and find the matching execution. Confirm the received source and request\_id. 5\. Send a second controlled request with source=other. Check the rule’s actual rejection result and whether any execution was created. Do not claim a specific status code until it is observed/configured. 6\. For a response-capable API flow, configure the supported final response and compare the caller’s body with the action result. For an acknowledgement-only webhook, inspect History for completion instead of treating HTTP 200 as the business result. [Handle errors and debug a flow](/userguide/operate-and-troubleshoot/handle-errors-and-debug-a-flow.md)