# API · Webhooks

> Which events exist, how many retries there are, in what format they arrive and how to confirm the state of a charge.

- kind: concept
- status: stable
- api_version: v1
- last_verified: 2026-10-20
- url: https://tilopay.com/en/developers/api/webhooks

## Recurrence [#recurrencia]

Six fields configured when **creating or editing a plan**. All optional.

| Field | What it is |
|---|---|
| `webhook_subscribe` | Subscription webhook |
| `webhook_payment` | Charge webhook |
| `webhook_rejected` | Rejected charge webhook |
| `webhook_unsubscribe` | Unsubscribe webhook |
| `webhook_reactive` | Reactivation webhook |
| `thanks_url` | **Not a webhook:** it is a GET callback |

## Payment links [#links-de-pago]

`webhook_url` is configured when creating the link.

## Retries [#reintentos]

| Source | Attempts | When it retries |
|---|---|---|
| Recurrence | 5 | When your response is 400, 404, 502, 504 or 403 |
| Purchases | 1 | — |

Delivery is considered successful on an **HTTP 200**. Respond 200 as soon as you receive the
event and process it separately: anything else counts as a failure, and purchases have no second
attempt.

## Format [#formato]

JSON.

## The card token [#token]

| Source | Token |
|---|---|
| Recurrence | **Not sent** |
| Purchases | Sent and **usable** |

## Origin verification [#verificacion]

> **Warning:** The only origin verification available is the `orderHash`, and its algorithm is not public:
> it is requested by writing to `soporte@tilopay.com`.
> 
> Until you have the algorithm, do not take irreversible business decisions from webhook content
> alone: confirm the state against the API before shipping or releasing a service.

## Main flow webhook [#processpayment]

> **Note:** `processPayment` also has a webhook. Its technical specification (the fields it sends) we deliver it when you request it, so your team can implement it:
> write to `soporte@tilopay.com` to receive it.