As of May 1, 2025, both versions of the Recharge API (2021-01 & 2021-11) require cursor-based pagination for responses that exceed 100 pages.

Requests that return more than 100 pages must now use cursor-based pagination. Otherwise, the request will result in an error.

Who is impacted?

There is no impact to merchants currently using these endpoints without cursor pagination — they have been added to a whitelist, and can temporarily continue using page-based pagination.

This change applies to merchants who are not currently using page-based pagination to return 100+ pages of data. Any new API requests will require the use of cursor-based pagination.

For more information on cursor-based pagination, see our API documentation.

Starting March 19th, 2025, we’re making changes to our retrieve, and list charge endpoints on API versions 2021-01 and 2021-11. Success, refunded, or partially- refunded processed charges over 90 days ago will no longer appear in the results. Please review your integration accordingly. 

In 2025, Recharge is thrilled to improve our speed, scalability, and data analysis capabilities for your store. These enhancements will lead to more robust features and faster API and page load times.

What You Need to Do

Please review your API integration for any impacts and update your API calls, if necessary, that fetch charges with a processed_at date older than 90 days (whether fetching an individual charge or a list of charges).

Please note:

• GET requests will only return charges processed within the last 90 days. Otherwise, it will result in an empty list.

Charge data processed over 90 days ago will remain available through the Exports tool in your Recharge merchant portal and within the Merchant portal UI.

Examples of unaffected API calls:

• [LIST CHARGES] /charges?status=queued
• [LIST CHARGES] /charges?status=error
• [RETRIEVE A CHARGE] /charges/{id}  (if it's a charge that does not have a processed_at date or the processed_at date is within the last 90 days)

Examples of API calls that may return partial results:

• [LIST CHARGES] /charges?processed_at_min=2024-01-01 (this would only return results that have a processed_at date in the last 90 days)
• [LIST CHARGES] /charges?status=success, queued (this would return all queued charges but only return success charges that have a processed_at date in the last 90 days)
• [LIST CHARGES] /charges?ids={id},{id},{id}  (this would only return charges that do not have a processed_at date or the processed_at date is within the last 90 days)

Examples of API calls that will result in an empty list:

• [LIST CHARGES] /charges?processed_at_max=2024-01-01 (any date over 90 days old)

Example of API calls that will result in a 404: 

• [RETRIEVE A CHARGE]/charge/{id} (if it's a charge with a processed_at date older than 90 days)

As of today, January 16th, the Recharge API will return HTTP 403 errors when requests come from an API token associated with stores that no longer have Recharge installed.

If a store reinstalls Recharge, their API token will be functional again.

Here is an example of the before and after:

• Currently: On May 10th, a customer enters their customer portal and opts to immediately ship an order that was scheduled for June 1st; we would maintain the charge date as June 1st.
• This change will begin coming into effect for some stores on May 21st: On May 10th, a customer enters their customer portal and opts to immediately ship an order that was scheduled for June 1st; we will update the charge date to May 10th to align with the processing attempt date. (This would happen regardless of whether the payment attempt succeeds or fails)

All merchants on the Pro plan or higher can now use the all-new Events API resource to fetch a read-only running log for all events on a store within the last 7 days. 

Uses of this resource include but are not limited to:

• Granular analytics
• Data synchronization
• Advanced troubleshooting and
• Recovery if webhook receivers experience short-term failure

How does it work? Review our API reference documentation.

You will now be able to use the Recharge API, more specifically the “update a subscription” endpoint, to make any changes to a canceled subscription. Moving forward, if your customers choose to reactivate their canceled subscriptions at any point, those subscriptions will continue to align with your current offerings, saving you time from manually making updates. This can be done using the new bulk updater and also works on the bulk update resource and in asynchronous batches. This also now works when bulk managing subscriptions in the Recharge admin UI.

How does it work? Learn more here.

When customers choose to skip or unskip, all operations will perform simultaneously, which can increase the speed of operations by 5x. Customers will see a decrease in waiting time once they choose to skip or unskip, and those customers that average more than one subscription or have onetimes will see an improvement.

How does it work? Learn more here.

With this improved endpoint, we've added functionality and information including: 

• Adding and removing variants on queued prepaid orders now correctly reflect on the delivery schedule
• Payment methods are now visible on the order within Delivery Schedules
• Prepaid orders are priced at zero, but we have maintained visibility for the original line item price

How does it work? Learn more here.

If you are on the Recharge Pro or Enterprise plan you can now read and update bundle-related data with new bundle selection endpoints. 

How does it work? Learn more here.