> ## Documentation Index
> Fetch the complete documentation index at: https://developers.ingopayments.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Webhooks

> Real-time event delivery across all Ingo products. Configure your endpoint, verify signatures, and handle the full transaction lifecycle as it happens.

Ingo delivers real-time updates to your configured webhook endpoint as events occur — recipient engagement, identity screening, payment outcomes, and session activity. The connection is one-way: Ingo posts to you. Your endpoint acknowledges receipt with a 2xx response, and the event payload is the authoritative record for everything that follows.

Every Ingo product fires webhooks. Event types, payload schemas, and correlation fields differ per product — the setup and verification requirements below apply to all of them.

***

## Endpoint Requirements

Register a static HTTPS endpoint with your Ingo integration manager before onboarding. Ingo posts webhook payloads as JSON to that URL on every qualifying event.

| Requirement  | Detail                                                            |
| ------------ | ----------------------------------------------------------------- |
| Protocol     | HTTPS only — HTTP endpoints are not accepted                      |
| TLS version  | TLS 1.2 minimum; TLS 1.3 recommended                              |
| Response     | Return any `2xx` status within 10 seconds                         |
| Content-Type | Ingo posts `application/json`                                     |
| URL          | Must be static — dynamic or session-scoped URLs are not supported |

<Warning>
  If your endpoint does not return a `2xx` response within the timeout window, Ingo will retry delivery. Design your handler to be idempotent — the same event may arrive more than once.
</Warning>

***

## TLS Requirements

Your endpoint must support at least one cipher suite from the lists below.

**TLS 1.3**

| Cipher Suite                            | Key Exchange | Strength |
| --------------------------------------- | ------------ | -------- |
| `TLS_AES_256_GCM_SHA384` (0x1302)       | ECDH x25519  | 256-bit  |
| `TLS_CHACHA20_POLY1305_SHA256` (0x1303) | ECDH x25519  | 256-bit  |
| `TLS_AES_128_GCM_SHA256` (0x1301)       | ECDH x25519  | 128-bit  |

**TLS 1.2**

| Cipher Suite                                           | Key Exchange | Strength |
| ------------------------------------------------------ | ------------ | -------- |
| `TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384` (0xc030)       | ECDH x25519  | 256-bit  |
| `TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256` (0xcca8) | ECDH x25519  | 256-bit  |
| `TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256` (0xc02f)       | ECDH x25519  | 128-bit  |

***

## IP Allowlist

Add the following Ingo IP addresses to your allowlist so webhook traffic can reach your endpoint.

<CardGroup cols={2}>
  <Card title="Sandbox" icon="flask">
    | IP Address       |
    | ---------------- |
    | `18.189.65.27`   |
    | `23.253.209.42`  |
    | `23.253.213.126` |
    | `23.253.22.48`   |
    | `3.130.108.242`  |
    | `3.134.254.69`   |
    | `3.142.181.231`  |
    | `104.130.74.57`  |
  </Card>

  <Card title="Production" icon="building">
    | IP Address     |
    | -------------- |
    | `64.88.183.84` |
    | `50.56.42.59`  |
    | `50.56.46.146` |
    | `50.57.62.142` |
  </Card>
</CardGroup>

***

## Handling Events

**Acknowledge first, process second.** Return a `2xx` response immediately, then process the payload asynchronously. Handlers that hold the connection open risk timeout retries and duplicate delivery.

**Design for idempotency.** Ingo retries unacknowledged deliveries. Use the `metadata.id` in the payload to detect and discard duplicates before they affect your system state.

**The API response is the source of truth.** Webhooks are an optional subscription layer for real-time status updates — they do not supersede the synchronous response. All transaction statuses, regardless of payment type, are always reflected in your daily SFTP reporting.

***

## Testing During Development

Webhook endpoints are registered by your Ingo integration manager — there is no self-service portal to update the URL your program is configured to call. Before beginning sandbox development, confirm your endpoint URL with your integration manager so it can be registered as part of your program setup.

If you need to receive webhooks on a local development machine, use a tunnel tool that provides a **persistent, stable URL** — a fixed subdomain or custom domain that does not change between sessions. Register that stable URL with your integration manager once. Ephemeral tunnels that generate a new URL on every restart require a configuration change with your integration manager each time, which is not practical for active development.

<Note>
  Contact your Ingo integration manager to update your registered webhook URL. Plan for this lead time when coordinating environment changes or moving from sandbox to production.
</Note>

***

## Webhook References

Event types, payload schemas, retry behavior, and signature details are documented per product.

<CardGroup cols={2}>
  <Card title="IngoPay Webhooks" icon="webhook" href="/docs/ingopay/webhooks/overview">
    Transaction outcomes for verify, process, and debit calls across all payment types.
  </Card>

  <Card title="Notify — Classic Webhooks" icon="webhook" href="/docs/notify-classic/webhooks/overview">
    Recipient engagement events from notification sent through funded.
  </Card>

  <Card title="Notify — Managed Parties Webhooks" icon="webhook" href="/docs/notify-managed/webhooks/overview">
    Full party lifecycle events including approvals, role delegation, and multi-party flows.
  </Card>

  <Card title="Embedded Account Capture Webhooks" icon="webhook" href="/docs/iframe/webhooks/overview">
    Session events for the hosted iFrame enrollment and payment selection experience.
  </Card>
</CardGroup>