Skip to content
Adoptiv

Inbound Webhooks

One generated address per source, sitting outside the login. It verifies the signature, refuses a redelivery, files the whole exchange, and hands what arrived to a flow as flat variables read by name.

One address outside the login, and the gates behind it

200
Credential set on this address
In this order
  1. 1The address, and whose it is
  2. 2Bounded before it is believed
  3. 3Per source, per minute
  4. 4Signature, or token, or neither
  5. 5Seen this delivery before
  6. 6Filed either way
compared in constant time, prefix tolerated
Delivery
/api/v1/webhooks/incoming/9tKq2xR7vLm4bYs1WnP0dHcE6fJa3Zu8
signed, and new
Answer
200
downstream: whatever flow you aimed it at
Blanked before the row is filed
  • authorization
  • cookie
  • x-webhook-token
  • x-api-key
  • proxy-authorization
generating a fresh path is how an integration gets cut off
every delivery is kept until the address itself is deleted
A log row is written for a refusal exactly as it is for an acceptance, with five request headers blanked first. A delivery that reaches the end can create a log row and then whatever flow you aimed it at, which includes writing a lead. Deals and tasks are not among the things it makes.
0
characters in the address it generates
0 hr
a delivery key is remembered for
0
request headers blanked before filing

Product figures from the platform’s own defaults - not customer averages

The mechanism

How it works.

01

The address is generated, and it is the first secret

Twenty-four random bytes rendered URL-safe make a thirty-two character path. Which workspace it belongs to is worked out from the hostname the request arrived on, so nothing identifying you needs to travel in the body. Generating a fresh path is how an integration gets cut off.

02

Signature first, shared token second, and neither is also allowed

Given a signing secret, the header is compared in constant time against a hash of the exact bytes received, with a prefix on the header tolerated. Given a token instead, it is read from a header, a bearer line or the query string. Set neither and the address accepts anybody, and nothing on the form insists you set one.

03

Everything is bounded before any of it is believed

A declared length over the ceiling is turned away before a byte is buffered, and the stream is severed at the ceiling as well, so a chunked body cannot slip past the first check. A per-minute counter sits in the shared cache. Refusals get filed exactly like acceptances do.

04

A redelivery is acknowledged, not replayed

The key comes from either standard header or, where the sender offers none, from a hash of the body itself, which covers the many services that send no key at all. Keys are remembered for a day. A repeat gets the same success answer, is marked duplicate in the log, and starts nothing downstream.

Where it sits

Two moments in every run.

Every run passes through the same seven. Inbound Webhooks is the lit ones, and everything either side of it is a different page in this category.

  1. 01
    Trigger

    the thing that happened first

  2. 02
    Enrol

    how somebody gets onto it

  3. 03
    Wait

    the pause, and what governs its length

  4. 04
    Branch

    the fork, and which side is taken

  5. 05
    Act

    the mail, the text, the task that goes out

  6. 06
    Measure

    what counts as it having worked

  7. 07
    Exit

    how somebody comes off it

The specifics.

8 facts
Address
A thirty-two character generated path per source. Regenerating it is how you revoke one
Signing
A hash over the raw body in a signature header, compared in constant time, prefix optional
Token fallback
Only where no signing secret is set: a header, a bearer line or a query parameter. Set neither and the address accepts anything sent to it, and both fields are optional on the form
Size ceiling
One megabyte unless raised, and fifty is as high as it goes
Rate limiting
Per source per minute, unlimited until you name a number, and it lets traffic through if the cache is unreachable
What a delivery can create
A log row always. Past that, whatever flow you aim it at, which includes writing a lead. Deals and tasks are not among the things it makes
Log retention
None. Every delivery is kept until the address itself is deleted, and deleting it takes the log with it
Not the same as
This is the way in, on an address you hand to a sender. Reading and writing records from outside is the REST API

More in Automation & Flows

13 capabilities

Sequences, dispositions and webhooks that act without being asked.

Sequence Builder

Thirteen node kinds on a canvas: send, wait, branch on behaviour, split, call task, tag, goal. Publish a version and in-flight leads keep their own place.

Email Sequences

Enrol a lead once and the sequence carries them: sends, waits, branches and exits, with a ledger that makes a duplicate send structurally impossible.

Branch Logic

Branch on whether they opened, clicked or replied, and on how the last call was dispositioned - so the next step answers what actually happened.

A/B Split Testing

Weighted splits assigned by a deterministic hash of the enrolment, so a lead always takes the same arm no matter how often that step is run again.

Wait & Timing

Hold a lead for minutes or days between steps, clamped to the sending window you set, so that an overnight wait never lands at four in the morning.

Sending Windows

Set the hours a sequence may send inside, as a fixed offset you enter yourself, and every wait is pushed forward into them before it is stored.

Suppression Lists

One do-not-contact roll per workspace, checked when a lead is enrolled and again inside the send, straight after that send has taken its own claim.

Call Tasks in Sequences

Drop a call step into a sequence and it raises an assigned task on the lead's owner, with the outcome the rep logs coming back as a branchable answer.

Goal Tracking

Name a linked deal as the outcome that means the sequence worked. Reaching it stamps goal met on the run and takes the branch you wired behind it.

Disposition Behaviours

Twenty-six behaviours attach to wrap-up codes, and twenty codes ship already pointing at one, so ending a call the right way books the follow-up.

Workflow Triggers

Six event types a CRM rule fires from: stage change, field update, new record, reassignment, schedule and inactivity, agreed in four places at once.

Conditional Logic

Eight comparison operators guarding each action, combined with AND and only AND, so a rule meaning either of two things is built twice, as two rules.

SMS in Sequences

A text is a step on the same canvas as the email and the call task, written into the real thread and carried out by the number it is going out from.

Automation & Flows

See inbound webhooks on your own floor.

Thirty minutes, your numbers and your data. We will set inbound webhooks up live and you can decide from the thing itself rather than from this page.

14-day trial · no card · migration included