Everything an AI agent can do with the Recharge API.

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

Endpoints29
API version2021-11
Last updated23 June 2026
Orientation

How the Recharge API works.

The Recharge API is how an app or AI agent works with a Recharge store: listing subscriptions, skipping or processing a charge, updating a customer, and managing the products and plans behind recurring orders. Access is granted through a merchant API token, and that token carries per-resource scopes set to read or read and write, so a call reaches only the resources its scopes allow. Recharge versions its API by date and can push events to a registered endpoint when something changes in the store.

29Endpoints
8Capability groups
13Read
16Write
9Permissions
Authentication
Recharge authenticates a call with a merchant API token sent in the X-Recharge-Access-Token header over HTTPS. The token is created in the Recharge admin, where each resource is set to no access, read, or read and write. The same token works across API versions; the version is chosen per request, not per token.
Permissions
A token carries per-resource scopes like read_subscriptions, write_subscriptions, read_customers, write_customers, read_orders, and write_orders. A request to a resource the token has no scope for returns a 403, so a token reaches only the resources it was granted. Some resources share a scope, for example charges and orders both fall under read_orders and write_orders.
Versioning
Recharge versions its API by date in YYYY-MM form, set per request with the X-Recharge-Version header, where a later date is a newer version. The 2021-11 version is the current dated release and 2021-01 is the earlier base version. A request without the header uses the account's configured default version.
Data model
Recharge is resource-oriented around recurring commerce: a Customer holds Addresses, a Subscription or Onetime sits on an address, and a Charge groups what bills together and produces an Order once processed. Products and Plans define what can be sold, and Bundle Selections describe the contents of a bundle. A state change can emit a webhook to a registered endpoint.
Connect & authenticate

Connection & authentication methods.

How an app or AI agent connects to Recharge determines what it can reach. There is a route for making calls with a merchant API token, and a route for receiving events as they happen, and each is governed by the token behind it and the scopes that token carries.

Ways to connect

REST API

The REST API takes JSON request bodies, returns JSON, and pages through lists with a cursor, at https://api.rechargeapps.com. A call authenticates with a merchant API token sent in the X-Recharge-Access-Token header, and selects a dated version with the X-Recharge-Version header.

Best forConnecting an app or AI agent to Recharge.
Governed byThe merchant API token and the scopes it carries.
Docs ↗

Webhooks

Recharge POSTs a JSON payload to an HTTPS endpoint registered through the webhooks endpoints, one per topic such as subscription/created or charge/paid. The receiver verifies the payload against the webhook's shared secret to confirm the request came from Recharge, so an integration learns about activity without polling.

Best forReceiving Recharge events at an app or AI agent.
Governed byThe shared secret on the registered webhook.
Docs ↗
Authentication

Merchant API token

A merchant API token is created in the Recharge admin, where each resource is set to no access, read, or read and write. It is sent in the X-Recharge-Access-Token header on every request. The token is the server-side credential for the merchant's own store, and a store can hold several tokens to separate integrations and spread rate-limit load.

TokenMerchant API token (X-Recharge-Access-Token header)
Best forServer-side access to a merchant's own Recharge store.
Docs ↗

Storefront token

A storefront token is a customer-facing credential used by client-side storefront integrations. It carries a narrower set of scopes, such as reading products, reading customers, and reading or writing subscriptions, so it can power a customer portal without exposing full merchant access.

TokenStorefront access token
Best forCustomer-facing storefront and portal experiences.
Docs ↗
Capability map

What an AI agent can do in Recharge.

The Recharge API is split into areas an agent can act on, like subscriptions, customers, charges, and orders. Each area has its own methods, and writes in some areas change recurring billing or move a charge toward processing.

Endpoint reference

Every Recharge 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

Subscriptions

Methods for working with subscriptions, the recurring line items on an address.9

Read-only; needs the read_subscriptions scope.

Acts onsubscription
Permission (capability)read_subscriptions
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitStandard limits apply

Read-only.

Acts onsubscription
Permission (capability)read_subscriptions
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitStandard limits apply

A core write; needs write_subscriptions.

Acts onsubscription
Permission (capability)write_subscriptions
VersionAvailable since the API’s base version
Webhook eventsubscription-created
Rate limitStandard limits apply

Swapping a subscription's product is performed by updating it, not a separate endpoint.

Acts onsubscription
Permission (capability)write_subscriptions
VersionAvailable since the API’s base version
Webhook eventsubscription-updated
Rate limitStandard limits apply

Stops recurring billing on the subscription.

Acts onsubscription
Permission (capability)write_subscriptions
VersionAvailable since the API’s base version
Webhook eventsubscription-cancelled
Rate limitStandard limits apply

Resumes recurring billing on a cancelled subscription.

Acts onsubscription
Permission (capability)write_subscriptions
VersionAvailable since the API’s base version
Webhook eventsubscription-activated
Rate limitStandard limits apply

Skips the next scheduled charge without cancelling the subscription.

Acts onsubscription
Permission (capability)write_subscriptions
VersionAvailable since the API’s base version
Webhook eventsubscription-skipped
Rate limitStandard limits apply

Moves the next charge date on the subscription.

Acts onsubscription
Permission (capability)write_subscriptions
VersionAvailable since the API’s base version
Webhook eventsubscription-updated
Rate limitStandard limits apply

Reassigns the subscription to another of the customer's addresses.

Acts onsubscription
Permission (capability)write_subscriptions
VersionAvailable since the API’s base version
Webhook eventsubscription-updated
Rate limitStandard limits apply

Customers

Methods for working with customers.3

Read-only; needs read_customers.

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

Read-only.

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

A core write; needs write_customers.

Acts oncustomer
Permission (capability)write_customers
VersionAvailable since the API’s base version
Webhook eventcustomer-updated
Rate limitStandard limits apply

Addresses

Methods for working with the addresses that subscriptions and charges sit on.2

Addresses are governed by the customers scopes; read needs read_customers.

Acts onaddress
Permission (capability)read_customers
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitStandard limits apply

Addresses are governed by the customers scopes; a write needs write_customers.

Acts onaddress
Permission (capability)write_customers
VersionAvailable since the API’s base version
Webhook eventaddress-updated
Rate limitStandard limits apply

Charges

Methods for working with charges, which group what bills together.5

Charges are governed by the orders scopes; read needs read_orders.

Acts oncharge
Permission (capability)read_orders
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitStandard limits apply

Read-only.

Acts oncharge
Permission (capability)read_orders
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitStandard limits apply

Charges are governed by the orders scopes; a write needs write_orders.

Acts oncharge
Permission (capability)write_orders
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitStandard limits apply

Attempts payment now; a success produces an order.

Acts oncharge
Permission (capability)write_orders
VersionAvailable since the API’s base version
Webhook eventcharge-paid
Rate limitStandard limits apply

Returns money on a processed charge; needs write_orders.

Acts oncharge
Permission (capability)write_orders
VersionAvailable since the API’s base version
Webhook eventcharge-refunded
Rate limitStandard limits apply

Orders

Methods for working with orders, the records of processed charges.2

Read-only; needs read_orders.

Acts onorder
Permission (capability)read_orders
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitStandard limits apply

Read-only.

Acts onorder
Permission (capability)read_orders
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitStandard limits apply

Products & Plans

Methods for working with the products and plans behind subscriptions.3

Read-only; needs read_products.

Acts onproduct
Permission (capability)read_products
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitStandard limits apply

Read-only; needs read_plans.

Acts onplan
Permission (capability)read_plans
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitStandard limits apply

A catalog write; needs write_plans.

Acts onplan
Permission (capability)write_plans
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitStandard limits apply

One-times & Bundles

Methods for one-time products and bundle selections on a subscription.3

One-times are governed by the subscriptions scopes; a write needs write_subscriptions.

Acts ononetime
Permission (capability)write_subscriptions
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitStandard limits apply

Bundle selections are governed by the subscriptions scopes and are available to Recharge Plus merchants.

Acts onbundle_selection
Permission (capability)read_subscriptions
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitStandard limits apply

Changes the bundle's contents; governed by write_subscriptions and available to Recharge Plus merchants.

Acts onbundle_selection
Permission (capability)write_subscriptions
VersionAvailable since the API’s base version
Webhook eventsubscription-updated
Rate limitStandard limits apply

Webhooks

Methods for registering and managing webhook subscriptions.2

Webhook management is not governed by a dedicated resource scope.

Acts onwebhook
Permission (capability)None required
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitStandard limits apply

Sets the topic and destination URL; webhook management is not governed by a dedicated resource scope.

Acts onwebhook
Permission (capability)None required
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitStandard limits apply
No endpoints match those filters.
Webhooks

Webhook events.

Recharge can notify an app when something happens in a store, like a subscription being created or a charge being paid. It POSTs a payload describing what changed to a registered endpoint, so an integration learns about activity without polling.

EventWhat it signalsTriggered by
subscription/createdA subscription was created on an address./subscriptions
subscription/updatedA subscription changed, like its quantity, frequency, product, next charge date, address, or bundle contents./subscriptions/{id}
/subscriptions/{id}/change_next_charge_date
/subscriptions/{id}/change_address
/bundle_selections/{id}
subscription/cancelledA subscription was cancelled and stops billing./subscriptions/{id}/cancel
subscription/activatedA cancelled subscription was reactivated and resumes billing./subscriptions/{id}/activate
subscription/skippedAn upcoming charge for a subscription was skipped./subscriptions/{id}/skip
charge/paidA charge processed successfully and payment was collected./charges/{id}/process
charge/refundedA processed charge was refunded, fully or partially./charges/{id}/refund
customer/updatedA customer's details changed./customers/{id}
address/updatedAn address changed, which can affect future charges on it./addresses/{id}
No events match that search.
Rate limits & pagination

Rate limits, pagination & request size.

Recharge limits how fast an app can call with a leaky-bucket model: a token holds up to a fixed number of requests that drains at a steady rate per second, and going over returns an error.

Request rate

Recharge meters requests with a leaky-bucket model per merchant token rather than a per-method cost. Each token holds a bucket of up to 40 requests that drains at 2 requests per second, so a steady 2 per second never trips a limit while short bursts up to 40 are allowed. When the bucket is full, further requests are rejected with HTTP 429 until it drains. A merchant gets this standard 1x1 allowance per token, and using more than one token spreads load across more buckets.

Pagination

List endpoints are cursor-based. A response includes next_cursor and previous_cursor fields, and the next page is fetched by passing the cursor value in the cursor query parameter. The page size is set with limit, which defaults to 50 and accepts up to 250. From the 2021-11 version on, a list response does not return a total count of records, so pagination moves forward and back by cursor rather than by page number.

Request size

A single list page returns at most 250 records, the maximum value of limit. Cursor values are opaque and tie a request to a specific position in a result set; a cursor cannot be combined with most filters once paging has begun.

Errors

Status codes & error handling.

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

StatusCodeMeaningWhat to do
400Bad RequestThe request was malformed or a parameter was invalid.Fix the request body or parameters and resend. The request is not retryable as-is.
401UnauthorizedNo valid merchant API token was provided.Send a valid token in the X-Recharge-Access-Token header, and rotate the token if it is compromised.
403ForbiddenThe token lacks the scope the request needs, for example calling a charges method without the orders scope.Grant the required read or read and write scope on the token, then resend.
404Not FoundThe requested object does not exist or is not visible to this token.Verify the object id and confirm the token has access to it.
422Unprocessable EntityThe request was well-formed but could not be processed, for example a value that fails a business rule.Read the error detail, correct the offending field, and resend.
429Too Many RequestsThe token's leaky bucket of 40 requests is full; the limit drains at 2 requests per second.Back off and retry after the bucket drains, and keep the steady rate at or under 2 requests per second.
500Internal Server ErrorAn error on Recharge's side.Retry with backoff, and contact Recharge support if it persists.
Versioning & freshness

Version history.

Recharge versions its API by date, set per request with a header, so an integration pins one dated version and moves up deliberately when a newer one ships.

Version history

What changed, and when

Latest version2021-11
2021-11Current version
Current dated version

The 2021-11 version is the current dated release of the Recharge API, selected per request with the X-Recharge-Version header. It introduced the payment_methods resource, renamed the shop endpoint to store, deprecated the collections endpoint, and changed pagination so list responses no longer return a total record count, moving forward and back by cursor instead.

What changed
  • Added the payment_methods resource.
  • Renamed the shop endpoint to store.
  • Deprecated the collections endpoint.
  • List responses no longer return a total record count; pagination is cursor-based with next_cursor and previous_cursor.
  • Added and removed fields across other objects.
2021-01
Base version

The 2021-01 version is the base dated release, a snapshot of the resources and endpoints at that time. It remains available for older integrations, while new integrations are directed to the latest dated version.

What changed
  • Initial dated snapshot of the API's resources and endpoints.
  • Included a total record count on list responses, later removed in 2021-11.

Pin a dated version with the X-Recharge-Version header and move up on a schedule that suits the integration.

Recharge changelog ↗
Questions

Recharge API, answered.

How does authentication work?+
A call sends a merchant API token in the X-Recharge-Access-Token header over HTTPS. The token is created in the Recharge admin and the bearer of the token is authorized for exactly the actions its scopes allow. There is no OAuth step for the merchant API; the token is the credential.
How do token scopes and permissions work?+
When a token is created, each resource is set to no access, read access, or read and write access, producing scopes like read_subscriptions and write_subscriptions. A request to a resource the token lacks a scope for returns a 403. Some resources share a scope, for example charges and orders are both governed by read_orders and write_orders.
How does API versioning work?+
Versions are date-based in YYYY-MM form, where a later date is newer. A request selects a version with the X-Recharge-Version header, such as 2021-11, and a request without the header uses the account's configured default. The 2021-11 version is the current dated release and changed pagination so list responses no longer return a total record count.
What happens when a rate limit is hit?+
Recharge uses a leaky bucket of 40 requests per token that drains at 2 per second. When the bucket fills, further requests return HTTP 429 until it drains. Staying at or under 2 requests per second avoids the limit, and short bursts up to 40 are allowed before throttling begins.
How does an agent receive events from Recharge?+
An integration registers a webhook with a topic, such as subscription/created or charge/paid, and Recharge POSTs a payload to the registered URL when that event occurs. This lets an app learn about activity without polling. Webhooks are managed through the webhooks endpoints.
Are charges and orders the same thing?+
No. A Charge groups the line items that will bill together on a date and moves through states like skipped, processed, or refunded. Once a charge processes successfully it produces an Order, the record of a completed transaction. Both charges and orders are governed by the read_orders and write_orders scopes.
Related

More e-commerce API guides for agents

What is Bollard AI?

Control what every AI agent can do in Recharge.

Bollard AI sits between a team's AI agents and Recharge. 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 Recharge 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.
Recharge
Retention Agent
View subscriptions ResourceOffReadFull use
Cancel subscriptions ActionOffReadFull use
Skip charges ActionOffReadFull use
Customers ResourceOffReadFull use
Per-agent access, set in Bollard AI, not in Recharge