A workflow doesn't have to stay inside Gleap. The custom API action calls an endpoint of yours during a conversation — to look up an order, check a subscription, or record something in your own system — and what comes back can be used by the steps that follow.
Add the step and give it four things:
A name — something descriptive like “Get customer orders”, since this is what you'll see in the flow later.
The URL to call.
Headers, if your endpoint needs authentication.
A request body, where you send something rather than only fetching.
Placeholders work in the URL, the headers, and the body, so you can pass through what Gleap already knows about the conversation — the contact, the ticket, values collected earlier in the flow.
This is the field that makes the rest work. You paste an example of what your API returns, and Gleap uses it to know which fields exist — so later steps can offer them to you instead of asking you to remember the shape of your own JSON.
The editor can send a test request and show you what came back. Do that before saving — it's the difference between finding out now and finding out from a customer who got a broken flow.
Once the call succeeds, its data is available downstream: put an order status into a message, branch on whether a subscription is active, store a value on the ticket.
Pair it with dynamic buttons where the options themselves come from your data — a customer choosing which of their three orders they're asking about is a far better experience than typing an order number.
Your endpoint will be slow or unavailable at some point, and the customer is waiting in a live conversation while it happens.
Keep the endpoint fast, return the smallest useful response, and give the flow a sensible path for when the data isn't there — handing over to a person is a perfectly good outcome, and better than a flow that stops with nothing said.
