Webhooks and HTTP requests: connecting any system to an AI workflow

No catalog covers every system a company uses. There is always a booking tool, an internal admin panel or an industry-specific platform that nobody has built a connector for. Two plain tools close that gap: a webhook, which lets another system start your workflow, and an HTTP request, which lets your workflow call another system.

Neither is glamorous, and both are worth understanding properly because that is where most integration bugs and security problems live.

The two directions#

Inbound (webhook). Something happens elsewhere, such as an order placed, a form submitted or a ticket created, and that system sends an HTTP POST with a JSON body to a URL you give it. Your workflow starts with that payload.

Outbound (HTTP request). Your workflow needs to look something up or make a change. It sends a GET, POST, PUT, PATCH or DELETE to another system's API and uses the response in later steps.

Together they let you connect to anything that has an API, without waiting for a dedicated connector.

Where MCP and Composio fit#

You have three ways to reach an outside system, and they suit different cases:

• A catalog integration when one exists for the tool you need. Connect the account once and use it. This is the least work.
• A tool server (MCP) when a vendor or your own team already exposes the system's actions as tools that an agent can call. The Model Context Protocol is a standard for that. Cadrix can connect an MCP server and use its tools like built-in ones.
• Composio as a gateway to a large set of third-party apps through one connection.
• A direct HTTP request when none of those fit, or when you want full control of exactly one call.

For anything that changes data, the direct HTTP route has one real advantage: you write down the exact request, so it is easy to review and to put an approval in front of.

Starting a workflow from a webhook#

Design the receiving side with these habits.

Acknowledge quickly, work later. Stripe's webhook documentation says an endpoint must return a 2xx status quickly, before any complex logic that might time out. Senders treat slow or failed responses as errors and retry. If your workflow takes a minute, make sure the sender gets its answer first and the work continues behind it.

Expect duplicates. The same documentation notes that endpoints may receive the same event more than once, and recommends logging the event IDs you have processed and skipping repeats. Build a duplicate check into the first steps: compare the event ID against a store of seen IDs, and stop if it is there.

Do not rely on order. Events can arrive out of order. If an "updated" event arrives before "created", your workflow should fetch the current state from the source rather than trust the sequence.

Verify the sender. An open URL that starts a workflow is an open door. Stripe's guidance is explicit: without verification, an attacker could send fake events to trigger actions such as fulfilling orders. Its events carry a signature in a header, which you check against a shared secret using the raw request body, and it includes a timestamp so old, replayed messages can be rejected. Many providers use a similar scheme.

If the sender signs its requests, verify the signature. If it only supports a shared secret in a header, check the header and reject anything that does not match. If it supports neither, put the workflow behind something that does, and treat the payload as untrusted content.

Calling an API from a workflow#

A reliable HTTP step has five parts.

1. Method and URL. Use the narrowest call that does the job. A lookup should be a GET.
2. Credentials from a connection. Keep API keys in the credential store, never in a prompt or in the URL. In Cadrix, connection secrets are encrypted at rest and not shown to builders or the model.
3. Headers and body. Set content type, add an idempotency key on writes where the API supports it, and keep the body as small as possible.
4. Response handling. Check the status code. Treat 2xx as success, retry only temporary errors, and send permanent errors to a failure path with the response body attached.
5. Parsing. Pull out only the fields later steps need, and validate them. An unexpected response shape should stop the run, not flow into a model prompt.

Treat responses as untrusted#

When a model reads a response from an outside system, that response is data that could contain instructions. A support ticket body, a product description or a web page can all include text that tries to steer the agent. Pass only the fields you need, label them as data in your prompt, and do not give the agent powers it should not have. Our post on prompt injection in workflow agents covers this in more depth.

Cadrix also blocks workflow HTTP and tool calls to private network address ranges, to reduce server-side request forgery. If you run Cadrix on your own network and need to reach an internal service, plan that with your administrator rather than trying to work around it.

Putting it together in Cadrix#

Here is an example: a booking platform posts a "cancellation requested" event, and the workflow decides whether to refund.

1. Webhook trigger receives the event. A first Condition checks the shared secret or signature header and stops the run if it is wrong.
2. A Custom Function or Condition checks whether this event ID has been handled before.
3. An HTTP step fetches the booking from the platform's API using a stored credential, so you work from current data rather than the payload alone.
4. An Agent reads the booking and your cancellation policy from a knowledge base and proposes a refund amount with its reasoning.
5. A Condition sends amounts above your limit to a Human Input approval step.
6. An HTTP step issues the refund with an idempotency key, and a final step sends the customer a message.

Every request and response is visible in the run trace, so when the booking platform changes a field name, you can see exactly which call returned what.

Common mistakes#

• Putting API keys in the URL or in the prompt text.
• Trusting any POST that reaches the URL.
• Processing the same event twice because the sender retried.
• Passing a whole response body into a prompt instead of the three fields you need.
• Retrying a write without an idempotency key.

Sources#

• Stripe docs, Receive Stripe events in your webhook endpoint
• Stripe API docs, Idempotent requests
• Model Context Protocol specification, Tools (2025-06-18)
• Cadrix security page
• Cadrix integrations