> ## Documentation Index
> Fetch the complete documentation index at: https://docs.recurso.dev/llms.txt
> Use this file to discover all available pages before exploring further.
# GoCardless Webhook
> Receive and process batched webhook events from the platform's GoCardless account.
This endpoint receives webhook deliveries from GoCardless for the platform's
own GoCardless account. Unlike the [Razorpay](/api-reference/webhooks/razorpay)
and [Stripe](/api-reference/webhooks/stripe) receivers, each GoCardless delivery
batches many events; Recurso verifies the whole body once and then processes
(and deduplicates) each event individually. Workspaces that connected their
own GoCardless account use the
[per-connection receiver](/api-reference/webhooks/gocardless-connection) instead.
This endpoint verifies the delivery using the platform's `GOCARDLESS_WEBHOOK_SECRET`.
Configure the URL `https://api.recurso.dev/webhooks/gocardless` in the GoCardless
Dashboard under **Developers > Webhook endpoints** with the same secret. Without
a registered webhook, authorized mandates stay `created` and never debit.
## Parameters
| Parameter | Type | Required | Description |
| ------------------- | --------------- | -------- | ------------------------------------------------------------------------------------ |
| `Webhook-Signature` | string (header) | Yes | HMAC-SHA256 hex signature of the raw request body, computed with the webhook secret. |
## Request Body
The raw GoCardless events payload: an object with an `events` array. Each event
is handled by its `resource_type` and `action`:
| Event | Effect |
| ------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------- |
| `billing_requests` / `fulfilled` | Activates the local mandate and stores the real `MD...` mandate id that future debits reference. |
| `mandates` / any action | Keeps the local mandate status in sync with GoCardless. |
| `payments` / `confirmed`, `paid_out` | Settles the invoice that references this payment (`open` → `paid`) and records the dunning success. |
| `payments` / `failed`, `cancelled` | No state change; the invoice stays `open` and dunning picks it up. |
| `payments` / `charged_back`, `late_failure` | Reverses a settled payment: the invoice reopens (`paid` → `past_due`) and the settlement cash leg is reversed in the ledger. |
Any other event is acknowledged and ignored.
## Example Request
GoCardless sends a POST request with a batch of events:
```bash theme={null}
curl -X POST https://api.recurso.dev/webhooks/gocardless \
-H "Content-Type: application/json" \
-H "Webhook-Signature: 3f1a9c0e7b2d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8091a2b3c4d5e6f708192a3b" \
-d '{
"events": [
{
"id": "EV0123456789ABCD",
"resource_type": "billing_requests",
"action": "fulfilled",
"links": {
"billing_request": "BRQ0123456789ABCD",
"mandate_request_mandate": "MD0123456789ABCD"
}
},
{
"id": "EV0123456789ABCE",
"resource_type": "payments",
"action": "confirmed",
"links": {
"payment": "PM0123456789ABCD"
}
}
]
}'
```
## Response
Returns `200 OK` once the batch has been processed. `processed` counts every
event that was accepted on this delivery, including the ones acknowledged and
ignored (an unknown `resource_type`, a `billing_requests` action other than
`fulfilled`, a payment id that no invoice references). It is not a count of
side effects. Events already recorded by an earlier delivery are skipped
silently and not counted, and an event whose handler returned an error is not
counted either.
```json theme={null}
{
"status": "ok",
"processed": 2
}
```
When mandate handling is not configured on the API, the batch is acknowledged
without processing:
```json theme={null}
{
"status": "ignored"
}
```
## Fields
| Field | Type | Description |
| ----------- | ------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `status` | string | `ok` when the batch was processed, `ignored` when mandate handling is not configured. |
| `processed` | integer | Number of events accepted on this delivery: the events in the batch minus duplicates minus events whose handler returned an error. Ignored events count. Present only when `status` is `ok`. |
An event whose handler returns an error (for example, a transient database
error while looking up the invoice for a payment id) is logged and left
unrecorded rather than failing the batch, so the next redelivery retries it.
A payment id that simply matches no invoice is not an error: it is
acknowledged, counted in `processed`, and recorded, so it is never retried.
Per-event deduplication skips the events that already completed, so nothing
is processed twice.
## Errors
| Status | Code | When | Fix |
| ------ | ------------------- | -------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------- |
| `400` | `validation_failed` | Request body could not be read, or is not valid JSON | Check the delivery in the GoCardless Dashboard; Recurso expects the raw events payload |
| `401` | `unauthorized` | `Webhook-Signature` does not match the HMAC-SHA256 of the raw body | Make sure the secret in the GoCardless webhook endpoint matches `GOCARDLESS_WEBHOOK_SECRET` |
| `503` | `internal_error` | `GOCARDLESS_WEBHOOK_SECRET` is not set on the API (the receiver fails closed), or the inbound-webhook dedup store is unavailable | Self-hosted: set `GOCARDLESS_WEBHOOK_SECRET` and restart; otherwise let GoCardless retry |
Errors use the standard envelope — see [Errors](/api-reference/errors).
## OpenAPI
````yaml POST /webhooks/gocardless
openapi: 3.1.0
info:
title: Recurso API
version: 1.0.0
description: |
The Recurso billing engine REST API.
Authenticate by passing your API key as a bearer token:
Authorization: Bearer
Obtain an API key by registering a tenant via `POST /auth/register`.
All authenticated endpoints live under the `/v1` prefix. Mutating
endpoints support idempotency via the `Idempotency-Key` header.
license:
name: MIT
identifier: MIT
servers:
- url: https://billing.example.com
description: >-
Example deployment — substitute the base URL of your own Recurso
deployment.
security:
- bearerAuth: []
tags:
- name: System
description: Health, version, and API metadata
- name: Auth
description: Tenant registration
- name: Plans
description: Product catalog plans
- name: Customers
description: Customer management
- name: Subscriptions
description: Subscription lifecycle
- name: Invoices
description: Invoices, PDFs, and Indian GST e-invoicing
- name: Coupons
description: Discounts
- name: Usage
description: Metered usage events
- name: Credit Notes
description: Customer credits
- name: Quotes
description: Quote-to-invoice lifecycle
- name: Webhooks
description: Webhook endpoint management and event feed
- name: Analytics
description: Revenue analytics
- name: Checkout
description: Public hosted checkout for invoices
- name: Payments
description: Payment order creation
- name: Inbound Webhooks
description: Receivers for payment-gateway callbacks (Razorpay, Stripe)
- name: Customer Portal
description: Customer-facing portal — magic-link auth and session-scoped data
- name: Developer
description: API key management
- name: Account
description: Tenant account settings
- name: Finance
description: Ledger accounts, entries, reconciliation, and revenue recognition
- name: Settings
description: Tax (GST) and e-invoicing (IRP) configuration
- name: Consents
description: Consent records for RBI-compliant recurring billing
- name: Referrals
description: Customer referral program
- name: Gifts
description: Gift subscriptions
- name: Mandates
description: UPI Autopay mandates
- name: Offline Payments
description: Virtual accounts and manually recorded payments
- name: Organizations
description: Multi-entity organizations grouping several tenants
- name: Accounting
description: QuickBooks / Xero accounting integrations
- name: Churn
description: Churn risk scoring and alerts
- name: Cancel Flows
description: Configurable retention flows shown at cancellation time
- name: Dunning
description: Dunning analytics and multi-channel dunning campaigns
paths:
/webhooks/gocardless:
post:
tags:
- Inbound Webhooks
summary: GoCardless webhook receiver (platform account)
description: |
Receives GoCardless webhook deliveries for the platform's own
GoCardless account. Each delivery batches multiple events; billing
request fulfilment activates the corresponding mandate and mandate
lifecycle events keep local status in sync. The raw body is verified
against the `Webhook-Signature` HMAC before any event is trusted.
Called by GoCardless, not by API consumers.
operationId: handleGoCardlessWebhook
parameters:
- name: Webhook-Signature
in: header
required: true
description: HMAC-SHA256 hex signature of the raw request body.
schema:
type: string
requestBody:
required: true
content:
application/json:
schema:
type: object
description: Raw GoCardless events payload.
responses:
'200':
description: Batch processed (individual events may be ignored).
content:
application/json:
schema:
type: object
properties:
status:
type: string
enum:
- ok
- ignored
processed:
type: integer
'400':
$ref: '#/components/responses/BadRequest'
'401':
$ref: '#/components/responses/Unauthorized'
security: []
components:
responses:
BadRequest:
description: The request body or parameters are invalid.
content:
application/json:
schema:
$ref: '#/components/schemas/Error'
Unauthorized:
description: Missing or invalid credentials (API key or session cookie).
content:
application/json:
schema:
$ref: '#/components/schemas/Error'
schemas:
Error:
type: object
required:
- error
properties:
error:
type: object
description: Structured error detail.
required:
- code
- message
properties:
code:
type: string
description: Stable machine-readable error code.
examples:
- validation_failed
- unauthorized
- forbidden
- not_found
- conflict
- rate_limited
- internal_error
- invalid_api_key
- key_mode_mismatch
- over_refund
- invoice_not_paid
- invoice_already_paid
message:
type: string
description: Human-readable explanation.
securitySchemes:
bearerAuth:
type: http
scheme: bearer
bearerFormat: API key
description: >-
Tenant API key obtained from `POST /auth/register` or `POST
/v1/developer/keys`.
````