Reference · built on requestConnectorPayments, billing & fraud

Recharge

Subscriptions, charges, orders, and customers from Recharge stores, with webhooks for charge and subscription events.

Request accessPricing ↗

About

Recharge is a subscription platform for online stores. It holds the subscriptions, the charges that bill them, the orders those charges produce, and the customers and payment methods behind them. Its REST API is versioned by date (2021-01 and 2021-11) and served from api.rechargeapps.com.

An operator reads charge and subscription webhooks as they fire, then proposes a skip, a next-charge-date change, or a refund for your approval. Every proposal leaves a receipt: what changed, why, and how to undo it.

This is a reference listing. It documents what Fibric would read from Recharge and what it could propose, based on the vendor's published interfaces. Fibric builds it under a managed deployment when you request it; selecting it here installs nothing.

Inputs

  • Subscriptions with status, next charge date, and address through GET /subscriptions and subscription/* webhook topics
  • Charges and their status (queued, success, error, refunded, partially_refunded, skipped) through GET /charges
  • charge/failed, charge/max_retries_reached, and charge/paid webhook topics as they fire
  • Orders produced by charges through GET /orders and the order/processed topic
  • Customer and payment method changes through customer/* topics, including customer/payment_method_updated
  • Charge activities, limited to the last 90 days when included in a call or webhook

Proposed actions

  • Target capability: propose skipping or unskipping a queued charge through POST /charges/{id}/skip and /unskip
  • Target capability: propose a refund on a charge through POST /charges/{id}/refund
  • Target capability: propose a new next charge date through POST /subscriptions/{id}/change_next_charge_date
  • Target capability: propose cancelling or reactivating a subscription through POST /subscriptions/{id}/cancel and /activate

Proposed actions are target capabilities. Every action runs propose-first and needs a validated deployment and the appropriate permissions.

What you can build

  • Recover a failed charge

    When charge/failed fires, the operator checks the customer's payment method and proposes a retry date or a skip. You approve; the change is made once.

    With Payment Retry

  • Spot cancellations as they happen

    subscription/cancelled events are grouped by reason and product. The operator drafts an outreach note for your review and records who was contacted.

    With Churn Watch

  • Pace dunning without duplicate messages

    charge/max_retries_reached marks the end of Recharge's own retries. The operator proposes the next contact step and records it so no customer is messaged twice.

    With Dunning Cadence

Requirements

  • A Recharge store and an API token with the scopes you grant, such as read_subscriptions, read_orders, and write_subscriptions
  • Webhooks created through POST /webhooks for the topics you want, pointed at an HTTPS endpoint
  • An X-Recharge-Version header, or account API settings, pinned to 2021-11
Authentication
A store API token sent in the X-Recharge-Access-Token header, with read and write scopes granted per resource.

Limits

  • List calls return 50 results by default and at most 250 per page, paged by cursor
  • Charge activities included in calls or webhooks cover only the last 90 days
  • Bundle Selections endpoints are available only on the Recharge Plus plan
  • The reference documents a 429 rate-limit response but publishes no request thresholds

Access and pricing

Reference listing. Fibric builds the connector under a managed deployment when you request it. Your quote covers the build, capabilities, usage, and support.

Request Recharge ↗

Questions and answers

Which webhook topics does Recharge publish?
Topics cover addresses, charges, customers, orders, and subscriptions. Examples are charge/paid, charge/failed, charge/max_retries_reached, subscription/cancelled, order/processed, and customer/payment_method_updated. You create a webhook with POST /webhooks and can ask for included objects such as customer or metafields.
How is the Recharge API versioned?
By date. The documented versions are 2021-01 and 2021-11. Requests use your account's API settings unless you send an X-Recharge-Version header. The same token works across versions.
Can the connector refund a charge?
It can propose one. A refund goes through POST /charges/{id}/refund only after a person approves it. The receipt records the charge, the amount, and who approved.
Ask about Recharge

Ask about the capabilities and requirements in this listing.

For project-specific requirements, contact Fibric.

This connector listing is developed, published, and supported by Fibric. It describes integration with Recharge through published interfaces. Third-party names and logos identify the systems an integration connects to; they are the property of their respective owners, who are not affiliated with Fibric and do not sponsor or endorse this listing. Trademark policy