An inbound connector holds what an outside system must present when it sends data in: External Services → Your org. A webhook trigger can optionally use one to verify the sender.
Outcome
Data arriving from outside is checked before a run starts.
1. Create the connector
Go to Connectors and choose New Connector. Pick Inbound for the direction, then the Integration Type.
HTTP API is for verifying a webhook sender. Choose an Authentication Type:
- API Key — Hodoflow generates the key rather than asking you for one: An API key will be auto-generated for this inbound connector. The sender presents it in a header.
- Signed webhooks (HMAC) — the sender signs each delivery with a shared secret and Hodoflow checks the signature. Paste the sender's signing secret and choose the Signature scheme that matches it.
If the sender is Stripe, Slack, HubSpot or Intercom, you do not need this form at all — see Providers Hodoflow already knows how to verify below.
Checkpoint: the connector appears under Connectors → Inbound.
Providers Hodoflow already knows how to verify
Every provider signs its webhooks slightly differently — which header carries the signature, and what exactly is signed alongside the body. For these, that is already built in:
| Provider | What is signed | Replay protection |
|---|---|---|
| Stripe | The timestamp and the body | Deliveries older than 5 minutes are refused |
| Slack | The version, timestamp and body | Deliveries older than 5 minutes are refused |
| HubSpot | The method, URL, body and timestamp | Deliveries older than 5 minutes are refused |
| Intercom | The body | None — a signature stays valid while the secret does |
| GitHub | The body | None — a signature stays valid while the secret does |
Go to Connectors → Gallery, open one of these providers and choose Set up incoming webhooks. Paste the signing secret and save. You do not choose a scheme, a header or a tolerance — Hodoflow already knows them.
This is a separate connection from calling the same provider: sending to Stripe needs an API key, receiving from Stripe needs the endpoint's signing secret, and plenty of organizations want only one of the two.
Checkpoint: the connection appears under Connectors → Inbound.
2. Save the generated API key — you only see it once
Right after you create an inbound API-key connector, a banner appears:
Save this API key now. This is the only time the full key will be shown. Copy it somewhere safe. You can regenerate it, but you can't view it again.
Copy it before dismissing the banner. Hodoflow encrypts it and will not display it again — reopening the connector shows an empty key field, not the value.
If you lose it, open the connector, set a new key in the API Key field, and save. Every sender using the old key must be updated.
Senders present it in the Authorization header on requests into Hodoflow.
Checkpoint: the key is in your password manager, not just your clipboard.
3. Use it
For webhook verification: open the webhook trigger's inspector and choose the connector under Inbound Authentication. The picker only appears when your organization has inbound connectors that carry an authentication method. Verification happens on top of the service account's token, not instead of it — Hodoflow does not accept unauthenticated ingestion either way.
Checkpoint: the trigger inspector names the connector.
How inbound connectors get a status
There is no Test connection button on an inbound connector — there is nothing for Hodoflow to dial. Status comes from real traffic instead:
- Five authentication failures inside a minute flips it to Failing.
- One success flips it back to Verified.
- Unverified means it has never been used and has not failed. Everything starts there.
The Connectors overview updates as that happens, without a refresh.
Common problems
The Inbound Authentication picker is missing. Your inbound connectors all use None as the authentication type. Only connectors with a method appear.
Every signed delivery is rejected. Check that the secret is the webhook endpoint's signing secret rather than the API key — for most providers they are different values issued in different places. If the scheme signs a timestamp, also check the sending system's clock: a delivery signed more than five minutes from now, in either direction, is refused on purpose.
The connector went Failing on its own. A sender is presenting the wrong key — five failures in a minute is the threshold. Check what the sender is sending before regenerating anything.
I dismissed the banner without copying the key. Set a new one on the connector's API Key field and update the sender. The old value is not recoverable.