API Reference

The Recharge API is primarily a REST API with some RPC endpoints to support common operations. It has predictable, resource-oriented URLs, accepts JSON-encoded request bodies, returns JSON-encoded responses, and uses standard HTTP response codes, authentication, and methods.

Related guides: Generate API tokens, Using the API



API and Platforms compatibility

Recharge offers hosted solutions and integrates with various ecommerce platforms to process recurring transactions with the setup of your choice. In order to be compatible with those platforms some of our API resources and endpoints may be limited in use to a subset of platforms. When that is the case we will flag with the help of tags the checkout/platform association for which that feature is compatible.
When there is no restriction of compatibility no tags will appear.
Below is a legend of the tags you may come across:


Tag Checkout solution Ecommerce platform
BigCommerce Recharge hosted BigCommerce
Custom Recharge hosted or API-first Custom
RCS Recharge hosted Shopify
SCI Shopify hosted Shopify

You may also come across other tags specifying regional restrictions (e.g. USA Only) or new releases (e.g. Alpha, Beta).



Intro image
Base URL
https://api.rechargeapps.com

Authentication

Recharge uses API keys to authenticate requests.

Each request to the API should contain an API token in the following header:

X-Recharge-Access-Token:store_api_token

Replace store_api_token with your API key.

All requests must be made over HTTPS.


API Token Scopes

Scopes can be set up from the API token edit page in Recharge to control the level of access of an API token.

The API currently supports the scopes below:

Write Read
read_accounts
write_batches read_batches
write_customers read_customers
write_discounts read_discounts
read_events
write_notifications
write_orders read_orders
write_payment_methods read_payment_methods
write_products read_products
write_subscriptions read_subscriptions
read_store
read_credit_accounts
read_credit_adjustments
GET /
curl -i -H 'X-Recharge-Access-Token: your_api_token'
-X GET

Versioning

All requests will use your account API settings, unless you send a X-Recharge-Version header to specify the version.
You can use the same token to make calls to all versions. When no version is specified it will default to the default version on your store.

Existing API Versions Release notes
2021-11 2021-11 release notes
2021-01

Responses

Recharge uses conventional HTTP response codes to indicate the success or failure of an API request. In general, codes in the 2xx range indicate success, codes in the 4xx range indicate an error that failed given the information provided ( e.g. a required parameter was omitted, a charge failed, etc ), and codes in the 5xx range indicate an error with Recharge’s servers.

200 - OK: Everything worked as expected.
201 - OK: The request was successful, created a new resource, and resource created is in the body.
202 - OK: The request has been accepted and is in processing.
204 - OK: The server has successfully fulfilled the request and there is no content to send in the response body.
400 - Bad Request: The request was unacceptable, often due to a missing required parameter.
401 - Unauthorized: No valid API key was provided.
402 - Request Failed: The parameters were valid but the request failed.
403 - The request was authenticated but not authorized for the requested resource (permission scope error).
404 - Not Found: The requested resource doesn’t exist.
405 - Method Not Allowed: The method is not allowed for this URI.
406 - The request was unacceptable, or requesting a data source which is not allowed although permissions permit the request.
409 - Conflict: You will get this error when you try to send two requests to edit an address or any of its child objects at the same time, in order to avoid out of date information being returned.
415 - The request body was not a JSON object.
422 - The request was understood but cannot be processed due to invalid or missing supplemental information.
426 - The request was made using an invalid API version.
429 - The request has been rate limited.
500 - Internal server error.
501 - The resource requested has not been implemented in the current version but may be implemented in the future.
503 - A 3rd party service on which the request depends has timed out.

Extending responses

Our API endpoints and webhooks allow developers to extend responses with additional data in order to optimize calls, allowing for simpler and more efficient implementations.

The API supports including additional objects when using a GET request to retrieve a list or a GET request to retrieve a record by a specific id. This is achieved by using an include query parameter in the request URL. The include value contains the object or objects you want to include in the response of your request. On routes where multiple includes are available, you are able to pass multiple values separated by a comma (include=customer,metafields). The below table defines available include values for commonly used resources of the API.

Webhooks support included_objects on the topics listed below. Webhook included_objects accepts an array of supported values ("included_objects": [ "customer", "metafields"]). Specifying included_objects will return an enriched payload, containing the original resource and the associated included objects.

Resource Endpoints Webhook topics Supported include values Supported included_objects values
Addresses GET /addresses
GET /addresses/:id		 address/created
address/updated		 customer
discount
payment_methods (beta)
subscriptions		 customer
metafields
Charges GET /charges
GET /charges/:id		 charge/created
charge/failed
charge/max_retries_reached
charge/paid
charge/refunded
charge/uncaptured
charge/upcoming
charge/updated		 metafields metafields
Customers GET /customers
GET /customers/:id		 customer/activated
customer/created
customer/deactivated
customer/payment_method_updated
customer/updated		 addresses
metafields
payment_methods (beta)
subscriptions		 addresses
metafields
Orders GET /orders
GET /orders/:id		 order/cancelled
order/created
order/deleted
order/processed
order/upcoming
order/updated		 customer
metafields		 customer
metafields
Products GET /products
GET /products/:id		 product/created
product/deleted
product/updated		 collections
metafields		 collections
metafields
Subscriptions GET /subscriptions
GET /subscriptions/:id		 subscription/activated
subscription/cancelled
subscription/created
subscription/deleted
subscription/skipped
subscription/updated
subscription/unskipped
subscription/paused		 address
metafields		 metafields

Page Based Pagination

By default API calls will return 50 results. By using the limit parameter that can be increased to 250 results.

When there are more results than can fit on a page you may loop through the results by using the page parameter.

To request a page, include page as a parameter in the url.

E.g. https://api.rechargeapps.com/subscriptions?limit=250&page=1

The example to the right shows a loop through all Subscription by page.

With minor changes this example can be used for looping through any object type: Customers, Addresses etc.


NOTE:
Page based pagination deep into large data sets is not recommended due to performance degradation. To paginate deeper into a data set, we recommend exploring cursor pagination instead.
Example Request
# request the first page (page=1)
curl -i -H 'X-Recharge-Access-Token: your_api_token'
 -X GET https://api.rechargeapps.com/subscriptions?limit=250&page=1
# request next page of results (page=2)
curl -i -H 'X-Recharge-Access-Token: your_api_token'
 -X GET https://api.rechargeapps.com/subscriptions?limit=250&page=2
Example Response
id: 123
id: 456
# ... continues through 250 records
page: 1 result_size: 250

id: 567
id: 678
# ... continues through 250 records
page: 2 result_size: 250

id: 567
id: 678
# ... continues through only 10 records, no further pages needed
page: 3 result_size: 10

Cursor Pagination

By default API calls will return 50 results. By using the limit parameter that can be increased to 250 results. When there are more results than the current limit a cursor may be used to request additional results.

Cursor based pagination is the preferred method for looping through all records in a given data set, as it is more performant than specifying a page number along with number of results. This method also provides more assurance that you will receive all of the records in a given set.

Cursor based pagination works by providing a reference to a specific item in a list of sequential data which will represent the cursor, such as a numeric id. You can then specify whether you would like to query records starting before or starting after that item.

For convenience, the API provides a Link header in all responses for which there are further pages. This header contains both a next_cursor and previous_cursor link, which is just a URL with an encoded page_info parameter that contains any filters from your first call, as well as markers to let the API know where it left off and where to begin for the next call.

Please note that the only compatible filter allowed to be used with cursors is limit.


Supported endpoints for Link
GET /addresses
GET /async_batches
GET /async_batches/:id/tasks
GET /charges
GET /customers
GET /discounts
GET /orders
GET /products
GET /subscriptions

NOTE:
/charges requests which supply either the updated_at_min or created_at_min filter will not currently return a Link header.
Requests which contain a filter for ids, shopify_product_ids will not return a Link header.
Example Request
URL="https://api.rechargeapps.com/charges?limit=5"

response=$(curl -s -w "%{http_code}" 
    -H 'X-Recharge-Access-Token: your_api_token'  
    -H 'X-Recharge-Version: 2021-11'  
    -X GET $URL)

 content=$(sed '$ d' <<< "$response") # get all but the last line which contains the status code

# Display results
echo $content | jq "."

# parse next url
echo "Next URL"
next_cursor=$(jq ".next_cursor" <<< "${content}")

# Notice next_cursor value is passed as page_info query param
echo "$URL&page_info=$next_cursor"

Sorting

The API supports sorting of results when using a GET request to retrieve a list. Sorting is achieved using a sort_by query parameter in the request URL. The sort_by value contains the parameter and sort direction for your results (ascending or descending), and available sort_by values vary between resources. The below table defines available sort_by options for commonly used resources.


Resource Supported sort_by_values
Address Default: id-desc
Options: id-asc id-desc updated_at-asc updated_at-desc
Async Batch Default: id-desc
Options: id-asc id-desc created_at-asc created_at-desc
Charge Default: id-asc
Options: id-asc id-desc created_at-asc created_at-desc updated_at-asc updated_at-desc charge_date-asc charge_date-desc
Customer Default: id-desc
Options: id-asc id-desc created_at-asc created_at-desc updated_at-asc updated_at-desc
Discount Default: id-desc
Options: id-asc id-desc created_at-asc created_at-desc updated_at-asc updated_at-desc
Metafield Default: id-desc
Options:id-asc id-desc updated_at-asc updated_at-desc
Onetime Default: id-desc
Options: id-asc id-desc created_at-asc created_at-desc updated_at-asc updated_at-desc
Order Default: id-desc
Options: id-asc id-desc created_at-asc created_at-desc shipped_date-asc shipped_date-desc shipping_date-asc shipping_date-desc updated_at-asc updated_at-desc
Product Default: id-desc
Options: id-asc id-desc created_at-asc created_at-desc updated_at-asc updated_at-desc title-asc title-desc
Subscription Default: id-desc
Options: id-asc id-desc created_at-asc created_at-desc updated_at-asc updated_at-desc
Webhook Default: id-desc
Options: id-asc id-desc

Addresses

Addresses represents one of the many shipping locations a customer may have. Subscriptions are tied to a given address. Each customer can have multiple address objects (many to one aka n:1) in the relationship.

Endpoints
POST
/customers/{id}/addresses
GET
/addresses/{id}
PUT
/addresses/{id}
DELETE
/addresses/{id}
GET
/addresses
GET
/addresses/count
POST
/addresses/validate
Expand

Charges

A charge is the representation of a financial transaction linked to the purchase of an item (past or future). It can be a transaction that was processed already or the representation of an upcoming transaction. A charge is linked to its corresponding Orders( one Order for pay as you go subscriptions and several for pre-paid). Order are created once the corresponding Charge is successful. After successful payment, the first order will be immediately submitted to the external platform if applicable (e.g. Shopify, BigCommerce).

Endpoints
GET
/charges/{id}
GET
/charges
GET
/charges/count
POST
/charges/{id}/change_next_charge_date
POST
/charges/{id}/skip
POST
/charges/{id}/unskip
POST
/charges/{id}/refund
POST
/charges/{id}/process
POST
/charges/{id}/capture_payment
Expand

Checkouts

Pro plan

BigCommerce

Custom

The checkout resource allows to create unique checkout experiences.
We currently support Stripe, Apple Pay, Google Pay, and Braintree as payment processor.

Related guides: Mobile payments

Important - The Checkout endpoints are only available for BigCommerce and Custom. Checkouts on Shopify must go through Shopify.

Endpoints
POST
/checkouts
GET
/checkouts/{token}
POST
/checkouts
PUT
/checkouts/{token}
GET
/checkouts/{token}/shipping_rates
POST
/checkouts/{token}/charge
Expand

Customers

The Customer object holds account and billing information. Email is unique on the customer; no two customers for a store can have the same email. Address is the child of the customer object. There can be many child addresses on a customer, but only one parent customer per address.

Endpoints
POST
/customers
GET
/customers/{id}
PUT
/customers/{id}
DELETE
/customers/{id}
GET
/customers
GET
/customers/count
GET
/customers/{id}/payment_sources

The customer object

The following fields are deprecated: stripe_customer_token, paypal_customer_token, authorizedotnet_profile_id, authorizedotnet_payment_profile_id. To add payment methods to a customer use 2021-11 /payment_methods instead

Attributes
  • id
    integer

    Unique numeric identifier for the customer.

  • accepts_marketing
    boolean

    Indicates whether the Customer gives consent for marketing communications.

  • billing_address1
    string

    The customer’s billing address.

  • billing_address2
    string

    An additional field for the customer’s billing address.

  • billing_city
    string

    The customer’s billing city.

  • billing_company
    string

    The customer’s billing company.

  • billing_country
    string

    The customer’s billing country.

  • billing_first_name
    string

    The customer’s billing first name. Required when creating a customer.

  • billing_last_name
    string

    The customer’s billing last name. Required when creating a customer.

  • billing_phone
    string

    The customer’s billing phone number.

  • billing_province
    string

    The customer’s billing province or state name.

  • billing_zip
    string

    The customer’s billing zip or postal code.

  • created_at
    datetime

    The date and time when the customer was created.

  • email
    string

    The email address of the customer.

  • first_charge_processed_at
    string

    Date when first charge was processed for the customer.

  • first_name
    string

    The customer’s first name.

  • has_card_error_in_dunning
    boolean

    Does have a credit card in dunning, can be true and false.

  • has_valid_payment_method
    boolean

    Is the payment method valid or not, can be true and false.

  • hash
    string

    The unique string identifier used in a customers portal link.

  • last_name
    string

    The customer’s last name.

  • number_active_subscriptions
    integer

    The number of active subscriptions for the customer.

  • number_subscriptions
    integer

    The number of subscriptions for the customer.

  • phone
    string

    The customer’s phone number.

  • processor_type
    string

    What the merchant processor customer is stored on.

  • reason_payment_method_not_valid
    string

    Why payment method is not valid.

  • shopify_customer_id
    string

    Shopify’s unique identifier for the customer.

  • status
    string

    Customer’s status, can be ACTIVE and INACTIVE.

  • updated_at
    datetime

    The date and time when the customer was last updated.

The customer object
{
  "id": 18819267,
  "accepts_marketing": true,
  "analytics_data": {
    "utm_params": []
  },
  "billing_address1": "3030 Nebraska Avenue",
  "billing_address2": null,
  "billing_city": "Los Angeles",
  "billing_company": null,
  "billing_country": "United States",
  "billing_phone": "3103843698",
  "billing_province": "California",
  "billing_zip": "90404",
  "created_at": "2018-11-14T08:40:38",
  "email": "example_mail@gmail.com",
  "first_charge_processed_at": null,
  "first_name": "Jacob",
  "has_card_error_in_dunning": false,
  "has_valid_payment_method": false,
  "hash": "18819267b1f9095be98f13a8",
  "last_name": "Bronowski",
  "number_active_subscriptions": 0,
  "number_subscriptions": 0,
  "phone": "+16175551212",
  "processor_type": null,
  "reason_payment_method_not_valid": null,
  "shopify_customer_id": null,
  "status": "INACTIVE",
  "stripe_customer_token": "cus_I9bJ...",
  "updated_at": "2018-11-14T08:40:38"
}

Create a customer

Custom

RCS

SCI

Create a customer in Recharge.

If you plan to add payment information, it must be the tokenized customer representation. We do not accept card data directly. Please make sure it starts with ‘cus’ and not with a 'tok’, as the 'cus’ is prefix for customer token, and 'tok’ is prefix for payment token.

Creating a customer in Recharge will not create the customer on any other platform at this time.

Write_Payments permission is only required when creating customers with payment token information, or updating payment token information on a customer.

Scopes: write_customers write_payments
Body Parameters
  • accepts_marketing
    boolean

    Indicates whether the Customer gives consent for marketing communications.

  • authorizedotnet_payment_profile_id
    integer
    *Deprecated

    Authorize.net customer payment profile id. Required when authorizedotnet_profile_id is provided.

  • authorizedotnet_profile_id
    integer
    *Deprecated

    Authorize.net customer profile id. If both authorizedotnet_profile_id and authorizedotnet_payment_profile_id is provided the authorize.net payment profile will be tokenized and associated with the created customer. The tokenized value is returned as customer’s authorizedotnet_customer_token field.

  • billing_address1
    string
    * Required

    The customer’s billing address 1.

  • billing_address2
    string

    An additional field for the customer’s billing address.

  • billing_city
    string
    * Required

    The customer’s billing city.

  • billing_company
    string

    The customer’s billing company.

  • billing_country
    string
    * Required

    The customer’s billing country.

  • billing_first_name
    string
    * Required

    The customer’s billing first name.

  • billing_last_name
    string
    * Required

    The customer’s billing last name.

  • billing_phone
    string

    The customer’s billing phone number.

  • billing_province
    string
    * Required

    The customer’s billing province or state name.

  • billing_zip
    string
    * Required

    The customer’s billing zip or postal code.

  • email
    string
    * Required

    The customer’s email address.

  • first_name
    string
    * Required

    The customer’s first name.

  • last_name
    string
    * Required

    The customer’s last name.

  • paypal_customer_token
    string
    *Deprecated

    The payment processor customer payment token.

  • phone
    string

    The customer’s phone number.

  • processor_type
    string

    What the merchant processor customer is stored on.

  • shopify_customer_id
    string

    The shopify customer id.
    _The provided “shopify_customer_id” must match the provided “email” in the Shopify database for the customer.

  • stripe_customer_token
    string
    *Deprecated

    The customer token, you will need to tokenize customers first on the payment processors end, and after you get the customer token, you can create the Recharge customer with it.

Responses
  • 200

    Success

    Show response object
POST
/customers 
curl 'https://api.rechargeapps.com/customers' \ 
 -H 'Content-Type: application/json' \ 
 -H 'X-Recharge-Access-Token: your_api_token' \ 
 -d '{
  "billing_address1": "3030 Nebraska Avenue",
  "billing_city": "Los Angeles",
  "billing_country": "United States",
  "billing_first_name": "Mike",
  "billing_last_name": "Flynn",
  "billing_phone": "3103843698",
  "billing_province": "California",
  "billing_zip": "90404",
  "email": "example_mail@gmail.com",
  "first_name": "Mike",
  "last_name": "Flynn",
  "stripe_customer_token": "Customer_payment_token"
}'
Response 
{
  "customer": {
    "id": 18819267,
    "accepts_marketing": true,
    "analytics_data": {
      "utm_params": []
    },
    "billing_address1": "3030 Nebraska Avenue",
    "billing_address2": null,
    "billing_city": "Los Angeles",
    "billing_company": null,
    "billing_country": "United States",
    "billing_phone": "3103843698",
    "billing_province": "California",
    "billing_zip": "90404",
    "created_at": "2018-11-14T08:40:38",
    "email": "example_mail@gmail.com",
    "first_charge_processed_at": null,
    "first_name": "Mike",
    "hash": "18819267b1f9095be98f13a8",
    "has_card_error_in_dunning": false,
    "has_valid_payment_method": false,
    "last_name": "Flynn",
    "number_active_subscriptions": 0,
    "number_subscriptions": 0,
    "phone": "+16175551212",
    "processor_type": null,
    "reason_payment_method_not_valid": null,
    "shopify_customer_id": null,
    "status": "INACTIVE",
    "stripe_customer_token": "cus_I9bJ...",
    "updated_at": "2018-11-14T08:40:38"
  }
}

Retrieve a customer

Retrieve one customer using the Recharge customer id.

Scopes: read_customers
Responses
  • 200

    Success

    Show response object
GET
/customers/{id} 
curl 'https://api.rechargeapps.com/customers/18819267' \ 
 -H 'X-Recharge-Access-Token: your_api_token
Response 
{
  "customer": {
    "id": 18819267,
    "accepts_marketing": true,
    "analytics_data": {
      "utm_params": []
    },
    "billing_address1": "3030 Nebraska Avenue",
    "billing_address2": null,
    "billing_city": "Los Angeles",
    "billing_company": null,
    "billing_country": "United States",
    "billing_phone": "3103843698",
    "billing_province": "California",
    "billing_zip": "90404",
    "created_at": "2018-11-14T08:40:38",
    "email": "example_mail@gmail.com",
    "first_charge_processed_at": null,
    "first_name": "Mike",
    "hash": "18819267b1f9095be98f13a8",
    "has_card_error_in_dunning": false,
    "has_valid_payment_method": false,
    "last_name": "Flynn",
    "number_active_subscriptions": 0,
    "number_subscriptions": 0,
    "phone": "+16175551212",
    "processor_type": null,
    "reason_payment_method_not_valid": null,
    "shopify_customer_id": null,
    "status": "INACTIVE",
    "stripe_customer_token": "cus_I9bJ...",
    "updated_at": "2018-11-14T08:40:38"
  }
}

Update a customer

Modify an existing customer to match the specified parameters.

Note: For US citizens parameter billing_zip is required when updating customer’s billing_country parameter

Scopes: write_customers
Body Parameters
  • accepts_marketing
    boolean

    Indicates whether the Customer gives consent for marketing communications.

  • email
    string

    Email address of the customer.

  • billing_address1
    string

    Customer’s billing address 1.

  • billing_address2
    string

    An additional field for the customer’s billing address.

  • billing_city
    string

    Customer’s billing city.

  • billing_company
    string

    An additional field for the customer’s company.

  • billing_country
    string

    Customer’s billing country.

  • billing_first_name
    string

    Customer’s billing first name.

  • billing_last_name
    string

    Customer’s billing last name.

  • billing_phone
    string

    Customers billing phone number.

  • billing_province
    string

    Customer’s billing province or state name.

  • billing_zip
    string

    Customer’s billing zip or postal code.

  • first_name
    string

    Customer’s first name.

  • last_name
    string

    Customer’s last name.

  • phone
    string

    The customer’s phone number.

  • shopify_customer_id
    integer

    Shopify’s customer id.

Responses
  • 200

    Success

    Show response object
PUT
/customers/{id} 
curl -X PUT https://api.rechargeapps.com/customers/18819267
 -H 'Content-Type: application/json'
 -H 'X-Recharge-Access-Token: your_api_token'
 -d '{"billing_address1": "3030 Nebraska Avenue"}'
Response 
{
  "customer": {
    "id": 18819267,
    "accepts_marketing": true,
    "analytics_data": {
      "utm_params": []
    },
    "billing_address1": "3030 Nebraska Avenue",
    "billing_address2": null,
    "billing_city": "Los Angeles",
    "billing_company": null,
    "billing_country": "United States",
    "billing_phone": "3103843698",
    "billing_province": "California",
    "billing_zip": "90404",
    "created_at": "2018-11-14T08:40:38",
    "email": "example_mail@gmail.com",
    "first_charge_processed_at": null,
    "first_name": "Mike",
    "hash": "18819267b1f9095be98f13a8",
    "has_card_error_in_dunning": false,
    "has_valid_payment_method": false,
    "last_name": "Flynn",
    "number_active_subscriptions": 0,
    "number_subscriptions": 0,
    "phone": "+16175551212",
    "processor_type": null,
    "reason_payment_method_not_valid": null,
    "shopify_customer_id": null,
    "status": "INACTIVE",
    "stripe_customer_token": "cus_I9bJ...",
    "updated_at": "2018-11-14T08:40:38"
  }
}

Delete a customer

Customer deletion will automatically cancel and delete all child Address, Subscription, Onetime, etc. resources of that customer to eliminate orphaned child data.

To delete a certain address without deleting the customer you can use the Delete Address endpoint.

Scopes: write_customers
Responses
  • 200

    successful response

    Show response object
DELETE
/customers/{id} 
curl -X DELETE https://api.rechargeapps.com/customers/18819267
 -H 'X-Recharge-Access-Token: your_api_token'
Response 
{}

List customers

Return a list of customers in your store.


## HTTP request examples

GET /customers
GET /customers?email=example@email.com
GET /customers?hash=143806234a9ff87a8d9e
GET /customers?limit=250
GET /customers?page=2
GET /customers?shopify_customer_id=98273498

Scopes: read_customers
Query Parameters
  • email
    string

    Returns the user linked to the email address provided.

  • created_at_max
    string

    Gets all customers created before this date.

  • created_at_min
    string

    Gets all customers created after this date.

  • hash
    string

    Returns the user linked to the given recharge customer hash.

  • ids
    string

    Filter customers by id. If passing multiple values, must be comma separated. Non-integer values will result in a 422 error

  • limit
    string

    Default: 50

    Max: 250

    Number of results.
    Default value is 50, maximum is 250.

  • page
    string

    Default: 1

    Page to show. Default value is 1.

  • shopify_customer_id
    string

    Returns the user linked to the given shopify_customer_id.

  • status
    string

    Returns users with specified status
    Values are 'ACTIVE’, and 'INACTIVE’.

  • updated_at_max
    string

    Gets all customers updated before this date.

  • updated_at_min
    string

    Gets all customers updated after this date.

Responses
  • 200

    successful response

    Show response object
GET
/customers 
curl 'https://api.rechargeapps.com/customers' \ 
 -H 'X-Recharge-Access-Token: your_api_token' \ 
 -d limit=3 -G
Response 
{
  "customers": [
    {
      "id": 18819267,
      "accepts_marketing": true,
      "analytics_data": {
        "utm_params": [
          {
            "utm_campaign": "spring_sale",
            "utm_content": "differentiate-content",
            "utm_data_source": "website_cookie",
            "utm_medium": "email",
            "utm_source": "newsletter",
            "utm_term": "test-term",
            "utm_time_stamp": "2019-12-16T23:57:28.752Z"
          }
        ]
      },
      "billing_address1": "3030 Nebraska Avenue",
      "billing_address2": null,
      "billing_city": "Los Angeles",
      "billing_company": null,
      "billing_country": "United States",
      "billing_phone": "3103843698",
      "billing_province": "California",
      "billing_zip": "90404",
      "created_at": "2018-11-14T08:40:38",
      "email": "example_mail@gmail.com",
      "first_charge_processed_at": null,
      "first_name": "Mike",
      "hash": "18819267b1f9095be98f13a8",
      "has_card_error_in_dunning": false,
      "has_valid_payment_method": true,
      "last_name": "Flynn",
      "number_active_subscriptions": 0,
      "number_subscriptions": 0,
      "reason_payment_method_not_valid": null,
      "shopify_customer_id": null,
      "phone": "+16175551212",
      "processor_type": null,
      "status": "INACTIVE",
      "stripe_customer_token": "cus_I9bJ...",
      "updated_at": "2018-11-14T08:40:38"
    }
  ]
}

Count customers

Retrieve a count of customers.


## HTTP request examples

GET /customers/count
GET /customers/count?created_at_max=2019-11-11
GET /customers/count?created_at_min=2019-11-11
GET /customers/count?created_at_min=2019-11-10&updated_at_max=2019-11-11&status=ACTIVE
GET /customers/count?status=ACTIVE
GET /customers/count?updated_at_max=2019-11-11
GET /customers/count?updated_at_min=2019-11-11

Scopes: read_customers
Query Parameters
  • created_at_max
    string

    Gets count of all customers created before this date.

  • created_at_min
    string

    Gets count of all customers created after this date.

  • status
    string

    Returns the count of users with the specified status
    Values are 'ACTIVE’, and 'INACTIVE’.

  • updated_at_max
    string

    Gets count of all customers updated before this date.

  • updated_at_min
    string

    Gets count of all customers updated after this date.

Responses
  • 200

    successful response

    Show response object
GET
/customers/count 
curl 'https://api.rechargeapps.com/customers/count' \ 
 -H 'X-Recharge-Access-Token: your_api_token'
Response 
{
  "count": 12057
}

Payment sources

BigCommerce

Custom

RCS

Retrieve payment sources for customer

This endpoint has been deprecated. Use 2021-01 /payment_methods instead

Scopes: read_customers
Query Parameters
  • cardholder_name
    string

    Identifies the owner of the credit card.

  • card_brand
    string

    Identifies the brand of the credit card.

  • card_exp_month
    string

    The month when the card expires.

  • card_exp_year
    string

    The year when the card expires.

  • card_last4
    string

    The last four digits of the card.

  • customer_id
    string

    Unique customer identifier.

  • has_card_error_in_dunning
    string

    If it has true value, then there was an error in the dunning process. There were no errors in the dunning process if it has false value.

  • payment_type
    string
    *Deprecated

    Identifies the payment type. It could have credit, debit, paypal or apple_pay values.

  • processor_name
    string

    Identifies the payment processor. It could have stripe, braintree or authorize value.

  • status
    string

    Identifies the status of the payment method. It could have active or failed value.

  • status_reason
    string

    Provides more information on why the payment method is not valid if status has failed value.

Responses
  • 200

    Success

    Show response object
GET
/customers/{id}/payment_sources 
curl 'https://api.rechargeapps.com/customers/18819267/payment_sources' \ 
 -H 'X-Recharge-Access-Token: your_api_token'
Response 
{
  "payment_sources": [
    {
      "billing_address": {
        "id": 1,
        "address1": "3030 Nebraska Avenue",
        "address2": null,
        "city": "Los Angeles",
        "company": null,
        "country": "United States",
        "first_name": "Mike",
        "last_name": "Flynn",
        "phone": "3103843698",
        "province": "California",
        "zip": "90404"
      },
      "cardholder_name": null,
      "card_brand": null,
      "card_exp_month": null,
      "card_exp_year": null,
      "card_last4": null,
      "customer_id": 18819267,
      "has_card_error_in_dunning": false,
      "payment_token": "cus_I9bJ...",
      "payment_type": "credit",
      "processor_name": "stripe",
      "status": "active",
      "status_reason": null
    }
  ]
}

Discounts

Discounts can be applied to checkout, or can be applied directly to an address. Depending on configuration they allow for single use, or recurring discounts.

Often discounts can be used combination with webhooks, such that when a specific event comes, it can apply a discount dependent on custom business logic.

There are various options that can be utilized for discounts such as minimum price, single use, recurring for a set number of charges, or ongoing. You can also set the date from which time the discount will become applicable begin, and when it can no longer be applied to a new subscription.

Endpoints
POST
/discounts
GET
/discounts/{id}
PUT
/discounts/{id}
DELETE
/discounts/{id}
GET
/discounts
GET
/discounts/count
POST
/addresses/{id}/apply_discount
POST
/charges/{id}/apply_discount
POST
/addresses/{id}/remove_discount
Expand

Metafields

BigCommerce

Custom

RCS

We now have metafields endpoint on our API!

Metafields feature allows you to add additional information to other resources. They can be used for adding custom fields to objects, and are useful for storing specialized information.

Endpoints
POST
/metafields
GET
/metafields/{id}
PUT
/metafields/{id}
DELETE
/metafields/{id}
GET
/metafields
GET
/metafields/count
Expand

Notifications

The Customer Notifications API is used to dispatch email notifications to customers within Recharge. The API uses your configured Recharge email templates, and will dispatch an email to the address associated with the indicated customer_id. Some email templates require variable values, which are sent through the Customer Notifications API via the template_vars attribute. See below examples for all available template types.

Currently, the Customer Notifications API can be used to dispatch Get Account Access, and Upcoming Charge emails. Support for additional email templates and message types will be added in the future. To view your email template configurations, see the Notifications Settings section in your Recharge Merchant Portal.

Endpoints
POST
/customers/{id}/notifications
Expand

Onetimes

Onetimes represent non-recurring line items on a QUEUED Charge.

Endpoints
POST
/addresses/{address_id}/onetimes
GET
/onetimes/{id}
PUT
/onetimes/{id}
DELETE
/onetimes/{id}
GET
/onetimes
Expand

Orders

An order is created after a charge is successfully processed. The order contains all the same json data as the charge. In case of a prepaid order creation, the order will be queued for a particular date and submitted on that date to shopify.

Endpoints
GET
/orders/{id}
PUT
/orders/{id}
DELETE
/orders/{id}
GET
/orders
GET
/orders/count
POST
/orders/{id}/change_date
PUT
/orders/{id}/update_shopify_variant/{remote_variant_id}
POST
/orders/clone_order_on_success_charge/{order_id}/charge/{charge_id}
POST
/orders/{id}/delay
Expand

Products

The subscription settings associated to a remote catalog product

Endpoints
POST
/products
GET
/products/{id}
PUT
/products/{id}
DELETE
/products/{id}
GET
/products
GET
/products/count
Expand

Shop

The shop endpoint includes basic info about your Recharge store setup.

Endpoints
GET
/shop
GET
/shop/shipping_countries
Expand

Subscriptions

Subscriptions are individual items a customer receives on a recurring basis.

A subscription is a product added to an address.

If store owner wants to sell multiple products as one subscription on 1 address it can be done by creating a product in Shopify that consists of multiple products e.g. 3 types of vegetables in the box, set of different shirts, etc. This multiple products appear on the store as 1 product, therefore it can be sold in a single subscription to 1 or more addresses.

Endpoints
POST
/subscriptions
GET
/subscriptions/{id}
PUT
/subscriptions/{id}
DELETE
/subscriptions/{id}
GET
/subscriptions
GET
/subscriptions/count
POST
/subscriptions/{id}/set_next_charge_date
POST
/subscriptions/{id}/change_address
POST
/subscriptions/{id}/cancel
POST
/subscriptions/{id}/activate
POST
/addresses/{id}/subscriptions-bulk
PUT
/addresses/{id}/subscriptions-bulk
DELETE
/addresses/{id}/subscriptions-bulk
Expand

Webhook endpoints

Webhooks are a mechanism for reacting to specific events that are triggered in the Recharge system.
For example, a checkout completion, a customer activation or subscription cancellation. Webhooks will deliver you the data of the specific event in real-time. This data can be used to custom code logic behind automated subscription management, dashboards creation, discounts applying…


Retries / Idempotency
Due to webhook retries, it’s possible that your application receives the same webhook more than once. Ensure idempotency of the webhook call by detecting such duplicates within your application.


When a webhook is triggered, the payload will be identical to the payload you would receive from another API endpoint.

For example, a webhook on subscription/created event will be identical to the payload for retrieving a subscription by ID from the Recharge API.

There are a lot of things that can be done via Webhooks: It can be used to collect all kinds of data from our API and then create custom a Dashboard to show how much and when your customers are buying in real time, or use all this data to do Analytics of some kind in order to create a better customer experience. Webhooks can be used as a “Trigger” on your backend to update subscription products.

If you have some kind of a Subscription where you want to change the Product that the customer gets every month, you can do it by waiting for an order/created webhook on your backend, and when it fires you can make an API call to change the Product of that subscription or the next shipping date, etc.


## Respond to a webhook

Your webhook acknowledges that it received data by sending a 200 OK response. Any response outside of the 200 range will let Recharge know that you didn’t receive your webhook. Recharge has implemented a 5 second time-out period. We wait 5 seconds, if our system doesn’t get a response in that period we consider that request as failed. Our system will try 20 times to send the same webhook over the next 2 days, if the request fails every time our system will delete this webhook. At this moment our system is logging those deleted webhooks.

Endpoints
POST
/webhooks
GET
/webhooks/{id}
PUT
/webhooks/{id}
DELETE
/webhooks/{id}
GET
/webhooks
POST
/webhooks/{id}/test
Expand

Webhooks explained

Here you will find what specific action triggers a given webhook.


Address webhooks

To use these webhooks your API Token must have read permissions for Customers enabled ( read_customer ).


Topic Explanation
address/created This will trigger when you create an address via API, or when you go through the checkout with a particular address for the first time with the same customer.
address/updated This will trigger when you update an address via API, or when you update the address via UI. It will also trigger whenever a subscription has been activated or cancelled.

Charge webhooks

To use these webhooks your API Token must have read permissions for Orders enabled ( read_orders ).


Topic Explanation
charge/created This will trigger when your customers checkout successfully (only on the UI checkout success).
charge/failed This will trigger every time we try to process a charge and it fails due to various reasons (insufficient funds, invalid CC info, expired CC, etc.) on both API and UI.
charge/max_retries_reached This will trigger after we attempt to process a charge 8 times, and it failed every time due to various CC issues. This can be triggered on both UI (manually retry a charge 8 times and fail) and API.
charge/paid This will trigger when a charge is successfully processed, both manually via UI and automatic recurring charge. This will not trigger on the checkout itself.
charge/refunded This will trigger when a charge is successfully refunded, either partially or in full. It will fire if a charge has been refunded both manually via UI and through an API request.
charge/upcoming This will trigger X days before the upcoming charge is scheduled. The default is 3 days but your store specific setting can be verified on the Notification Settings page in the description of the Upcoming charge customer notification.
charge/updated This will trigger when applying a discount, a change to charge that recalculates shipping rates as well as if next_charge_date is updated on charge endpoint charges/<charge_id>/change_next_charge_date.
charge/deleted This will trigger when a subscription is cancelled and upcoming charges are deleted.

Checkout webhooks

To use these webhooks your API Token must have read permissions for Orders enabled ( read-orders ).


Topic Explanation
checkout/created This will trigger when a checkout is successfully created.
checkout/completed Will be deprecated.
checkout/processed This will trigger when a checkout is successfully processed.
checkout/updated This will trigger when a checkout is successfully updated.

Customer webhooks

To use these webhooks your API Token must have read permissions for Customers enabled ( read_customers ).


Topic Explanation
customer/activated This will trigger when you activate* a customer
* activating means that you have added a subscription to a customer who didn’t have an active subscription previously.
customer/created This will trigger when you create a customer via API or go through the checkout with a particular email address for a first time customer.
customer/deactivated This will trigger when the last subscription a customer had expires, so he no longer has ANY active subscriptions (which means there are no QUEUED charges/orders for this customer).
customer/payment_method_updated This will trigger only* when you update the payment_token from the UI
* We are working on triggering this when you do the update from the API as well.
customer/updated This will trigger when you update a customer via both API and UI.
customer/deleted This will trigger when you delete a customer via both API and UI.

Onetime webhooks

To use these webhooks your API Token must have read permissions for Subscriptions enabled ( read_subscriptions ).


Topic Explanation
onetime/created This will trigger when you create a one time product via API.
onetime/deleted This will trigger when you delete a one time product via API.
onetime/updated This will trigger when you update a one time product via API.

Order webhooks

To use these webhooks your API Token must have read permissions for Orders enabled ( read_orders ).


Topic Explanation
order/created This will trigger when an order is created (when a charge is successfully processed)
* In case of prepaid Orders there will be multiple order/created webhooks fired, one for every queued order created at once.
order/deleted This will trigger when an order is deleted.
order/processed This will trigger when the order is processed (when an order goes from status queued to status success). This will not trigger on checkout.
order/upcoming This will trigger X days before a QUEUED (prepaid) order is scheduled to be processed. The default is 3 days.
order/updated This will trigger when an order is updated.

Plan webhooks

To use these webhooks your API Token must have read permissions for Products enabled ( read_products ).


Topic Explanation
plan/created This will trigger when a plan is created by one of the following methods: via API, via Merchant portal or when using the 2021-01 Products endpoint.
plan/deleted This will trigger when a plan is deleted by one of the following methods: via API, via Merchant portal or when using the 2021-01 Products endpoint.
plan/updated This will trigger when a plan is updated by one of the following methods: via API, via Merchant portal or when using the 2021-01 Products endpoint…

Subscription webhooks

To use these webhooks your API Token must have read permissions for Subscriptions enabled ( read_subscriptions ).


Topic Explanation
subscription/activated This will trigger when you activate a subscription via API or UI.
subscription/cancelled This will trigger when you cancel a subscription via API or UI. An involuntary subscription cancelled due to max retries reached will only trigger the charge/max_retries_reached webhook and not the subscription/cancelled webhook.
subscription/created This will trigger when you create a subscription via API or when you go through the checkout on UI.
subscription/deleted This will trigger when you delete a subscription via API or UI.
subscription/skipped This will trigger when you skip a subscription within a charge, meaning that you only skip a particular subscription (the subscription_id you send in the body) in that charge if there are multiple subscriptions related to that charge.
subscription/unskipped This will trigger when you unskip a subscription within a charge, meaning you only unskip a particular subscription (the subscription_id you send in the body) in that charge if there are multiple subscriptions related to that charge.
subscription/updated This will trigger when you update a subscription via API (PUT method) or when you update the subscription via UI. This will also trigger when you update next charge date on Customer Portal, or when you change it using subscription endpoint subscriptions/ <subscription_id>set_next_charge_date.
subscription/swapped This will trigger when you swap a subscription product for a given address to a different product or product variation API or UI.
subscription/paused This will trigger when a customer pauses a subscription from within the customer portal.

Other webhooks

To use these webhooks your API Token must have read permissions for Store enabled ( read_store ).


Topic Explanation
app/uninstalled This will trigger when you uninstall OAuth app on your store.
recharge/uninstalled This will trigger when Recharge is uninstalled.
store/updated This will trigger when and update has been made to the store.

Webhook validation

Webhooks created through the API can be verified by calculating a digital signature. Each Webhook request includes an X-Recharge-Hmac-Sha256 header which is generated using the API Client Secret, along with the data sent in the request.

API Client Secret is not the same as your API token and it can be found at:
Recharge Dashboard—>Integrations—>API Tokens—>Click on your token
Edit API Token page will appear and there you will find API Client Secret

The request_body must be in JSON string format. Validation will fail even if one space is lost in process of JSON string generation.

Then use code similar to the example by adapting it to the programming language that you are using for your project.

Related guides: Example code for validating webhooks

Example Request:

Async batch endpoints

The Async batches API can be used for processing large volumes of operations asynchronously, in order to reduce aggregate processing time and network traffic when interacting with many unique objects. For example, a user can leverage async_batches to create 1000 discounts with only 3 API requests.

As shown in the diagram below, the necessary steps to create and process a batch are:

1. Create an async_batch with the desired batch_type

2. Add tasks (individual operations) to your batch. You can add up to 1,000 tasks with each request, up to 10,000 tasks per batch.

3. Submit the batch for processing. Until a batch is submitted for processing, no tasks are attempted.

4. You may retrieve the batch to view progress details while it processes, or register for the async_batch/processed webhook to receive immediate notification of batch completion.

5. Page through the tasks in the batch to view results of each completed or failed task.

Related guides: Examples of Async batches

Endpoints
POST
/async_batches
GET
/async_batches/{id}
GET
/async_batches
POST
/async_batches/{batch_id}/process
Expand

Async batch tasks

Most commonly, the response from listing tasks on an async_batch id will be identical to the body of a singular request to standard Recharge API endpoints. However, in some instances there are variations from the standard list task response body. See below for examples corresponding to each batch_type.

Related guides: Examples of async batches

Endpoints
POST
/async_batches/{batch_id}/tasks
GET
/async_batches/{batch_id}/tasks
Expand

Token information

This resource allows a caller to inspect basic information regarding the token in use. It will only return a single object related to the calling token ( ie - a call with api_token.id=1 will only return information regarding api_token.id=1.

Endpoints
GET
/token_information
Expand