GoCardless 429 rate_limit_exceeded: too many requests per minute

What GoCardless says

GoCardless's rate limits page gives the figure: 1,600 requests per minute on a standard integration and 1,600 per minute and merchant on a partner integration. When that is exceeded, the API returns the 429, and GoCardless notes that these requests are safe to retry: “These requests are safe to retry.”. To know when, it points to the response headers: ratelimit-limit, ratelimit-remaining and ratelimit-reset.

Where so many requests come from

The limit counts every request to the API, not just those that create payments. With the connector, each payment against a stored mandate is one request, whether it comes from a subscription renewal or a payment registered with the customer's payment method. Each event for a payment that reaches Odoo is another, because the connector doesn't rely only on the notification: it requests that payment from GoCardless and applies the status it returns. A large batch at the same time, such as many renewals at once while events for earlier payments arrive, adds up both.

GoCardless classifies this reason among the invalid_api_usage errors, those caused by how the request is made, and for those it asks you to alert your dev team. A single 429 doesn't need that; one that repeats every day does.

What the connector does

1. It reads the ratelimit-reset header and works out how long is left: the time it gives minus the Odoo server's time.
2. It waits that time, at least 1 second and at most 65. If the header is missing or can't be read, it waits 1 second. The cap prevents a wrongly set clock from leaving the Odoo process waiting forever.
3. It repeats the request only once.
4. If the repeat also gets a 429, it no longer waits: it treats it like any other rejection from the API.

The connector doesn't count its requests or throttle them in advance. It doesn't read ratelimit-remaining: it only waits when GoCardless has already replied with a 429.

If the second attempt also hits the limit

It depends on what Odoo was doing at that moment.

• If it was a payment, the transaction goes to “Error” with “GoCardless rejected the request.” and, below it, GoCardless's message with rate_limit_exceeded and the request_id in square brackets. The invoice remains pending payment.
• If it was applying a GoCardless event, the webhook answers 500 so that GoCardless sends the notification again, and events already applied are not applied twice. The hourly recovery also doesn't leave behind an event that failed: it requests it again on the next pass.

A 429 is not the same as a payment with no response. Without a response, the connector doesn't know whether GoCardless created the payment, so it leaves it pending and sends it again, with the same key, in less than an hour. With a 429 there is a response: GoCardless did not accept the request, which is why the transaction is left in error.

The connector writes these texts in English, so in an English-language Odoo they appear exactly as quoted here, whether a user or a scheduled action triggers them: “GoCardless rejected the request.” Here the message is the same whoever launches the payment, including a scheduled action such as a subscription renewal.

What to do

• Open the transaction from the invoice, with the “Payment Transaction” button at the top; the transactions menu only appears in developer mode, and it doesn't exist in Odoo 20. If the message names rate_limit_exceeded, GoCardless rejected that request because of the limit, not because of the customer or their mandate.
• After a while, charge the invoice again with the customer's stored payment method.
• If it happens often, check the Odoo server time: the wait is calculated by subtracting it from the ratelimit-reset time, and a clock running fast shortens it.
• If you need GoCardless, save the request_id from the message: its documentation asks you to include it when contacting its support.

With our connector

In Odoo 17, 18, 19 and 20 the connector treats the 429 as a pause: it waits for the time GoCardless asks for, repeats once and, if the limit persists, leaves the transaction in error with the request_id so you know what happened and what to give GoCardless.

Keep reading