Everything an AI agent can do with the GoCardless API.

A reference guide for building AI agents: every method, how to authenticate, and the permissions each one needs.

Endpoints28
API version2015-07-06
Last updated23 June 2026
Orientation

How the GoCardless API works.

The GoCardless API is how an app or AI agent collects bank payments: creating a customer, setting up a mandate to take Direct Debit, charging a payment, or running recurring billing through subscriptions. Access is granted through an access token, and the token is created as read-only or read-write, so its level decides whether a call can only look or can also make changes. GoCardless versions its API by date, and it pushes events when a resource changes so an integration learns about activity without polling.

28Endpoints
9Capability groups
15Read
13Write
2Permissions
Authentication
GoCardless authenticates every call with an access token, created in the dashboard and sent in an Authorization header using the Bearer scheme. Every request must also send a GoCardless-Version header naming the dated API version it expects. The JavaScript Flow uses a separate publishable access token. Partners acting for a merchant obtain a token through OAuth instead.
Permissions
A GoCardless access token is set to read-only or read-write when it is created. There are no finer per-resource scopes, so the token's level, not the resource, decides whether a call can only read or can also write. A read-only token calling a write method returns a 403. This is why per-agent control belongs in a gateway in front of the API.
Versioning
GoCardless versions its API by date, like 2015-07-06, sent in the GoCardless-Version header on every request. A new dated version is only minted for a breaking change, so additive features ship without a new version string. The latest released version is 2015-07-06.
Data model
GoCardless is resource-oriented REST: JSON requests and responses over HTTPS at predictable paths like /payments and /mandates. A payment is collected against a mandate, which authorises an integration to debit a customer's bank account; recurring billing combines customers, mandates, and subscriptions. A change to a resource emits an event delivered by webhook. Lists are cursor-paginated, and a create is made safe to repeat with an Idempotency-Key header.
Connect & authenticate

Connection & authentication methods.

How an app or AI agent connects to GoCardless determines what it can reach. There is a route for making calls, a route for receiving events, and a hosted server that exposes GoCardless to agents, and each is governed by the access token behind it and the level that token was given when it was created.

Ways to connect

REST API

The REST API takes JSON request bodies, returns JSON, and pages through lists with a cursor, at https://api.gocardless.com for live and https://api-sandbox.gocardless.com for sandbox. Every call sends an access token in an Authorization Bearer header and names the dated API version in a GoCardless-Version header. Updates use PUT, not PATCH, which is not allowed.

Best forConnecting an app or AI agent to GoCardless.
Governed byThe access token and the read-only or read-write level it was given.
Docs ↗

MCP server

A hosted Model Context Protocol server at https://mcp.gocardless.com, announced 18 February 2026, exposes GoCardless to AI agents and LLM clients. It gives a model structured knowledge of the API and integration patterns, and lets it query a live GoCardless account in natural language, like asking how many payments are overdue today.

Best forConnecting an AI agent to GoCardless through MCP.
Governed byThe credentials the MCP connection authenticates with.
Docs ↗

Webhooks

GoCardless POSTs events to an HTTPS endpoint registered in the dashboard or via the API. The body is signed with an HMAC SHA256 hex digest of the request body, using the endpoint's secret, supplied in a Webhook-Signature header. The receiver recomputes and compares the digest before processing, so a forged webhook is rejected.

Best forReceiving GoCardless events at an app or AI agent.
Governed byThe signing secret on the webhook endpoint.
Docs ↗
Authentication

Access token

An access token is created in the GoCardless dashboard and sent in an Authorization header using the Bearer scheme. It is created as read-only or read-write, and that level applies to every resource the token can reach; there are no finer per-resource scopes. A token must never be exposed in client code.

TokenBearer access token
Best forServer-side calls for a single GoCardless account.
Docs ↗

Publishable access token

A publishable access token is used by the GoCardless JavaScript Flow, which collects bank account details in the browser. It is limited to the client-safe operations that flow needs and is safe to use in front-end code, unlike a standard access token.

TokenPublishable access token
Best forClient-side bank account collection (JavaScript Flow).
Docs ↗

OAuth (partners)

A partner integration acting for many merchants uses OAuth: a merchant authorises the partner app, the partner exchanges the resulting code for an access token tied to that merchant's account, and an introspect API checks a token's validity. The rate limit then applies per merchant.

TokenOAuth access token tied to a merchant account
Best forPartners connecting to merchant accounts they don't own.
Docs ↗
Capability map

What an AI agent can do in GoCardless.

The GoCardless API is split into areas an agent can act on, like customers, mandates, payments, subscriptions, payouts, and refunds. Each area has its own methods, and writes in some areas set up or collect real bank payments.

Endpoint reference

Every GoCardless API method.

Filter by method, access, or permission, or search any path. Select a row for version detail, rate limits, the related webhook event, and the source.

MethodEndpointWhat it doesAccessPermissionVersion

Customers

Methods for working with customers, the people an integration collects from.5

Needs a read-write token. Restricted in live unless payment pages are scheme-compliant; otherwise use the Billing Requests API.

Acts oncustomer
Permission (capability)read-write
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitStandard limits apply

Readable with a read-only token.

Acts oncustomer
Permission (capability)read-only
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitStandard limits apply

Readable with a read-only token.

Acts oncustomer
Permission (capability)read-only
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitStandard limits apply

Needs a read-write token.

Acts oncustomer
Permission (capability)read-write
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitStandard limits apply

Needs a read-write token; cancels related mandates and subscriptions.

Acts oncustomer
Permission (capability)read-write
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitStandard limits apply

Customer bank accounts

Methods for working with the bank accounts a mandate debits.4

Needs a read-write token. Restricted in live unless payment pages are scheme-compliant; otherwise use the Billing Requests API.

Acts oncustomer_bank_account
Permission (capability)read-write
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitStandard limits apply

Readable with a read-only token; account numbers are returned masked.

Acts oncustomer_bank_account
Permission (capability)read-only
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitStandard limits apply

Readable with a read-only token.

Acts oncustomer_bank_account
Permission (capability)read-only
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitStandard limits apply

Needs a read-write token; once disabled the account cannot be re-enabled.

Acts oncustomer_bank_account
Permission (capability)read-write
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitStandard limits apply

Mandates

Methods for working with mandates, the authorisation to debit a customer.4

Needs a read-write token. Restricted in live unless payment pages are scheme-compliant; otherwise use the Billing Requests API.

Acts onmandate
Permission (capability)read-write
VersionAvailable since the API’s base version
Webhook eventmandates-event
Rate limitStandard limits apply

Readable with a read-only token.

Acts onmandate
Permission (capability)read-only
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitStandard limits apply

Readable with a read-only token.

Acts onmandate
Permission (capability)read-only
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitStandard limits apply

Needs a read-write token; ends authority to debit the customer.

Acts onmandate
Permission (capability)read-write
VersionAvailable since the API’s base version
Webhook eventmandates-event
Rate limitStandard limits apply

Payments

Methods for working with payments collected against a mandate.5

Needs a read-write token; collects real money. Send an Idempotency-Key to avoid a double charge on retry.

Acts onpayment
Permission (capability)read-write
VersionAvailable since the API’s base version
Webhook eventpayments-event
Rate limitStandard limits apply

Readable with a read-only token.

Acts onpayment
Permission (capability)read-only
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitStandard limits apply

Readable with a read-only token.

Acts onpayment
Permission (capability)read-only
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitStandard limits apply

Needs a read-write token; only works before the payment is submitted.

Acts onpayment
Permission (capability)read-write
VersionAvailable since the API’s base version
Webhook eventpayments-event
Rate limitStandard limits apply

Needs a read-write token; only valid for a failed payment.

Acts onpayment
Permission (capability)read-write
VersionAvailable since the API’s base version
Webhook eventpayments-event
Rate limitStandard limits apply

Subscriptions

Methods for working with subscriptions, recurring payments on a mandate.2

Needs a read-write token; schedules recurring collection.

Acts onsubscription
Permission (capability)read-write
VersionAvailable since the API’s base version
Webhook eventsubscriptions-event
Rate limitStandard limits apply

Needs a read-write token; the mandate stays active for other payments.

Acts onsubscription
Permission (capability)read-write
VersionAvailable since the API’s base version
Webhook eventsubscriptions-event
Rate limitStandard limits apply

Payouts

Methods for reading payouts sent from GoCardless to the creditor's bank.2

Readable with a read-only token.

Acts onpayout
Permission (capability)read-only
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitStandard limits apply

Readable with a read-only token.

Acts onpayout
Permission (capability)read-only
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitStandard limits apply

Refunds

Methods for working with refunds returned to a customer.2

Needs a read-write token; refunds are only available once the creditor has the can_create_refunds flag set.

Acts onrefund
Permission (capability)read-write
VersionAvailable since the API’s base version
Webhook eventrefunds-event
Rate limitStandard limits apply

Readable with a read-only token.

Acts onrefund
Permission (capability)read-only
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitStandard limits apply

Events

Methods for reading the events that record what happened to resources.2

Readable with a read-only token.

Acts onevent
Permission (capability)read-only
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitStandard limits apply

Readable with a read-only token; the same events are pushed by webhook.

Acts onevent
Permission (capability)read-only
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitStandard limits apply

Creditors

Methods for working with creditors, the entities that collect payments.2

Readable with a read-only token.

Acts oncreditor
Permission (capability)read-only
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitStandard limits apply

Readable with a read-only token.

Acts oncreditor
Permission (capability)read-only
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitStandard limits apply
No endpoints match those filters.
Webhooks

Webhook events.

GoCardless can notify an app when something happens to a resource, like a payment being confirmed or a mandate being cancelled. It sends events describing what changed, so an integration learns about activity without polling.

EventWhat it signalsTriggered by
paymentsAn event on a payment, like it being confirmed, paid out, failed, cancelled, or charged back. The action field names what happened./payments
/payments/:id/actions/cancel
/payments/:id/actions/retry
mandatesAn event on a mandate, like it being created, becoming active, being cancelled, failing, or expiring. The action field names what happened./mandates
/mandates/:id/actions/cancel
subscriptionsAn event on a subscription, like it being created, payment being created on schedule, being cancelled, or finishing./subscriptions
/subscriptions/:id/actions/cancel
refundsAn event on a refund, like it being created, paid, or failing./refunds
payoutsAn event on a payout, like it being paid into the creditor's bank account.In-app only
No events match that search.
Rate limits & pagination

Rate limits, pagination & request size.

GoCardless limits how fast an app can call, by a request rate measured per minute, and it pages through long lists with a cursor.

Request rate

GoCardless applies a single rate limit across all API requests, currently 1000 requests per minute. For a partner integration making calls on behalf of a merchant, the limit is 1000 requests per minute per merchant. The current ceiling is returned in the ratelimit-limit response header, with ratelimit-remaining and ratelimit-reset showing how many calls are left in the window and when it resets. Going over returns HTTP 429 with a rate_limit_exceeded error, and those requests can be safely retried.

Pagination

Lists are cursor-paginated. A request pages with after, the id of the object immediately following the page, or before, the id of the object immediately preceding it, and limit sets the page size. The response carries a meta.cursors object holding the after and before values to fetch the next or previous page, so an integration walks a list without offsets.

Request size

The limit parameter defaults to 50, with a maximum of 500 and a minimum of 1. Custom metadata allows up to 3 key-value pairs, with key names up to 50 characters and values up to 500 characters.

Errors

Status codes & error handling.

The status codes an agent should handle, and what to do about each.

StatusCodeMeaningWhat to do
400invalid_api_usageBad Request. The request could not be understood, usually due to malformed syntax. An invalid_api_usage error covers using the API incorrectly, like a missing required header or a malformed body.Read the errors array in the response body, fix the request, and resend. Alert the dev team; do not retry unchanged.
401unauthorizedThe request did not provide a valid Authorization header, or the user making it has been disabled.Confirm a valid access token is being sent, and rotate it if it is compromised.
403forbiddenThe token is valid but lacks permission for this resource, for example a read-only token calling a write method.Use a read-write token for write calls, or scope the action out of the agent's allowed set.
404not_foundThe requested resource was not found, or the authenticated user cannot access it.Verify the resource id and confirm the token's account can see it.
409idempotent_creation_conflictA create reused an Idempotency-Key that already succeeded, or the resource already exists. The error carries links.conflicting_resource_id.Treat the conflicting resource as the result, or use a fresh idempotency key per distinct operation.
422validation_failedThe request was well formed but invalid. Each error in the response names a field and a message describing what is wrong. invalid_state covers a request that conflicts with the resource's current state.For validation_failed, correct the named fields and resend. For invalid_state, alert the end user and do not retry.
429rate_limit_exceededToo many requests arrived in the current window. The ratelimit-remaining and ratelimit-reset headers explain the limit.Back off until the window resets, then retry. These requests can be safely retried.
500internal_server_errorAn error occurred within GoCardless while processing the request. It is rare and may also appear as request_timed_out.Retry the request, and report it to GoCardless support with the request_id if it persists.
Versioning & freshness

Version history.

GoCardless versions its API by date. A request names the version it expects in a header, and a new dated version is only minted for a breaking change.

Version history

What changed, and when

Latest version2015-07-06
2015-07-06Current version
Current released version (GoCardless Pro)

GoCardless versions its API by date, sent in the GoCardless-Version header on every request, and only mints a new dated version for a breaking change. 2015-07-06 is the latest released version. It made resource structure and date handling consistent across the API.

What changed
  • Removed the /helpers endpoint, replaced by individual first-class resource endpoints.
  • Renamed subscription start_at and end_at to start_date and end_date.
  • Enforced date formatting on payment charge_date and similar date fields, with dates using a _date key and timestamps using an _at key.
2015-04-29Feature update
Previous dated version

The dated version immediately before 2015-07-06. GoCardless kept it available through to 6 January 2016 to give integrations a migration window.

What changed
  • Superseded by 2015-07-06; supported until 6 January 2016.

Pin the dated version a request sends and move up deliberately when a new one ships.

GoCardless API changelog ↗
Questions

GoCardless API, answered.

How does an app authenticate to the GoCardless API?+
An access token is created in the GoCardless dashboard and sent on every request in an Authorization header using the Bearer scheme, for example Authorization: Bearer your_access_token. Every request must also send a GoCardless-Version header naming the dated API version. Calls are only accepted over HTTPS; an unsecured connection returns a tls_required error.
What permissions or scopes does a GoCardless token have?+
A GoCardless access token is created as read-only or read-write. There are no finer per-resource scopes, so a single token's level applies to every resource it can reach: a read-only token can list and get but not create or cancel, and a read-write token can do both. A read-only token calling a write method returns a 403. To scope an individual agent to specific resources or actions, that control has to sit in a gateway in front of the API.
How does GoCardless version its API?+
Versions are dated, like 2015-07-06, and every request sends the version it expects in a GoCardless-Version header. A new dated version is only released for a breaking change, so additive features arrive without a new version string. The latest released version is 2015-07-06, and a previous version is kept available for a stated migration window when a new one ships.
How do I make a payment request safe to retry (idempotency)?+
A create request can carry an Idempotency-Key header. GoCardless allows that key to be used for only one successful creation, so a retry after a network timeout will not take a payment twice. A repeat with a used key returns a 409 idempotent_creation_conflict error whose links.conflicting_resource_id points at the resource the first request created. The official client libraries generate this key automatically.
How do I verify a GoCardless webhook is genuine?+
GoCardless signs the body of each webhook POST with an HMAC SHA256 hex digest, using the secret of the webhook endpoint the event is sent to, and supplies it in a Webhook-Signature header. The receiver recomputes the digest over the raw request body and compares it before processing the event, so a forged or tampered webhook is rejected.
What is a mandate and why is it needed before a payment?+
A mandate is the customer's authorisation for an integration to collect Direct Debit from their bank account. A payment is created against a mandate, so the mandate has to be set up and active first. Mandates are reusable, so once one exists an integration can collect one-off payments or run a subscription against it without asking the customer again.
What is the difference between the sandbox and live environments?+
GoCardless has two environments with separate base URLs and separate access tokens: a sandbox at api-sandbox.gocardless.com for testing, where no real money moves, and live at api.gocardless.com. The whole API is available in sandbox, while live adds restrictions, like requiring the Billing Requests API to create customers, bank accounts, and mandates unless an integration's payment pages are approved as scheme-compliant.
Related

More finance API guides for agents

What is Bollard AI?

Control what every AI agent can do in GoCardless.

Bollard AI sits between a team's AI agents and GoCardless. Grant each agent exactly the access it needs, read or write, resource by resource, and every call is checked and logged.

  • Set read, write, or full access per agent, never a shared GoCardless token.
  • Denied by default, so an agent reaches only what has been explicitly allowed.
  • Every call recorded in plain English: who, what, where, and the decision.
GoCardless
Collections Agent
View payments ResourceOffReadFull use
Create payments ActionOffReadFull use
Cancel mandates ActionOffReadFull use
Customers ResourceOffReadFull use
Per-agent access, set in Bollard AI, not in GoCardless