# Inbound connectors

> Verify who is sending data into Hodoflow before a run starts.

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](#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.

## Next step

[Receive webhooks](/help/workflows/webhook-triggers), or [Connection and
authentication errors](/help/credentials-connections/connection-errors).