Serverless integration
Take a webhook from any system and deliver it to yours, in the shape yours expects
We give you a URL. Point anyone's webhook at it, write the mapping in a text box, and we deliver to your endpoint — signed, with retries, and without you hosting anything.
The sender
receives
APIBrasil
rewrites the body
Your system
delivers and retries
When this solves something
Every case below is the same problem: one system announces it one way, the other only understands another.
The invoice was paid
The gateway announces it with its own fields; your ERP expects the fields you defined when you wrote it.
An order came in
The platform fires a fat event, and your internal system needs three fields out of it.
The partner only fires GET
It sends everything in the querystring; your endpoint expects POST with JSON. Neither side is going to change.
You need to trust what arrives
Require an agreed header on the way in, and get everything HMAC-signed on our side to verify on arrival.
How it works
Three steps, and only the third one asks for attention.
Create the route
You get a public URL, with a secret baked in, only yours.
Point the webhook at it
In the sender's panel, paste the URL where your server's URL is today.
Write the mapping
A JSON with braced keys for the values that arrive. The preview shows the result as you type.
The mapping is a JSON with holes in it
You write the body YOUR system expects and mark with braces the places where the incoming values go. The preview runs in the browser, so it answers as you type.
What arrives
{
"event": "charge.paid",
"data": {
"id": "ch_9f2",
"amount": 14990,
"customer": { "name": "Ana Ribeiro" }
}
}Your template
{
"pedido": "{data.id}",
"valor": "{data.amount}",
"cliente": "{data.customer.name}",
"observacao": "{data.note}",
"recebido_em": "{_received_at}"
}What leaves
{
"pedido": "ch_9f2",
"valor": "14990",
"cliente": "Ana Ribeiro",
"observacao": "",
"recebido_em": "2026-08-28T03:14:07Z"
}The three rules that prevent most mistakes
A dot goes one level down
To reach a nested field you write the path with a dot. There is no second syntax to learn.
A missing field comes out empty
Forwarding doesn't fail over one missing field: its slot comes out empty and the rest is delivered.
A list is not flattened
A list arrives whole, as JSON, in the slot where you asked for it. An array index isn't stable between one delivery and the next — a template pointing at the first item passes the test and fails in production.
Two fields nobody sent, and you can use
{_raw}The received body, whole, for whoever wants to forward without rewriting anything.
{_received_at}The instant the call arrived — something the destination almost never has a way to know on its own.
The leading underscore exists so they never collide with a field of the same name from the sender.
How you know it was us
Everything that leaves here can be signed. You verify the signature on arrival and drop what doesn't match — that's what separates your webhook from anyone who found your address.
HMAC SHA-256 in a header
The signature travels in a fixed header, computed over the exact body that leaves. Same scheme as the workflow callback: if you've integrated with one, you don't write the check twice.
The inbound side is protected too
The receiving URL comes with a secret baked in, and you can require an agreed header. Whoever doesn't know both doesn't get in.
GET signs the empty string
A request with no body signs an empty string on both sides. It's the classic divergence — one side signing nothing, the other signing braces — and it's settled at the source.
What it accepts at both ends
The inbound side follows the sender. The outbound side follows your system. The two don't have to match.
| What | Inbound | Outbound |
|---|---|---|
| Method | POST, GET, PUT or PATCH | POST, GET, PUT or PATCH |
| Where the content goes | Body or querystring, however it arrives | Body or querystring, however you choose |
| Headers | Require whichever you want | Build whichever the destination asks for |
| Signature | Secret in the URL | HMAC SHA-256, optional |
DELETE isn't on the list, and that's deliberate
A webhook is a notification: the sender is saying something happened, and the four verbs above are the ones that carry content to describe what. DELETE as a notification trigger doesn't exist in the field — offering it would create a combination that never arrives.
It costs nothing
The forwarder has no plan of its own, doesn't consume balance and doesn't charge per delivery. It needs an APIBrasil account, and that's it.
Free with the account
The same account you use for the APIs opens the forwarder. There's no upgrade to make and no product to buy.
It doesn't touch your balance
Forwarding isn't a query: nothing that passes through here shows up on the API invoice.
And it saves you a server
What this replaces is an endpoint of yours in the air, with a domain, a certificate and someone on call when it goes down.
The first route takes about two minutes
Create the account, open the forwarder and point a test webhook at it. If the mapping is right, you see the result before you save.
Free with an APIBrasil account.
Sign up with no card. No lock-in: cancel whenever you want.