.png)
Recharge Integration Guide
Connect Recharge subscription, customer, order, charge, and product data with enterprise systems through REST APIs, selected GraphQL use cases, and webhook events.
Recharge integration options at a glance
Recharge’s primary integration method is its versioned REST API, which supports merchant and subscription operations across Customers, Addresses, Subscriptions, Orders, Charges, and Products. Recharge also provides a Storefront API based on GraphQL for supported storefront scenarios, while selected resource events can be delivered through webhooks. Martini can consume these endpoints in workflows, receive webhook requests through an API or workflow trigger, paginate large collections, and map Recharge JSON into downstream application models. API tokens and OAuth 2.0 credentials can be stored as Martini environment configuration or secrets. Large synchronizations should use checkpoints, controlled concurrency, and rate-limit-aware retries rather than assuming a bulk export API.
| Integration point | Supported by Recharge? | Common use cases | How Martini supports it |
|---|---|---|---|
| REST APIs | Yes | Recharge’s primary merchant integration interface supports retrieving and changing Customers, Addresses, Subscriptions, Orders, Charges, and Products, as well as managing webhooks. Use the current documented API version for new implementations. | Martini can consume authenticated Recharge REST endpoints from workflows, paginate collections, transform JSON, expose normalized APIs, and apply business rules around subscription and order operations. |
| GraphQL APIs | Limited | Recharge provides a Storefront API based on GraphQL for supported storefront use cases. It has distinct authentication, permissions, and resource coverage from the merchant REST API. | Martini can consume the Recharge Storefront GraphQL API when the required use case and credentials are available, while REST remains the usual choice for back-office orchestration. |
| Webhooks | Limited | Recharge supports webhook notifications for selected customer, address, subscription, order, and charge-related events. Coverage is not universal across all operations or state transitions. | Martini can expose an API or workflow start trigger to receive, verify, deduplicate, and route Recharge webhook requests to downstream workflows. |
| Pagination and incremental synchronization | Yes | Recharge collection endpoints support pagination. Changed-resource synchronization can use updated timestamps, resource status, or another documented filter where available. | Martini can process pages in a scheduled workflow, maintain checkpoints, limit concurrency, and retry throttled or transient requests. |
| Bulk or asynchronous APIs | Not confirmed | A general-purpose bulk export or asynchronous batch API was not confirmed. Large transfers should use paginated REST requests unless a specific account or API version documents another feature. | Martini can orchestrate controlled batch processing with pagination, checkpointing, and rate-limit-aware scheduling rather than assuming bulk support. |
| Authentication | Yes | Recharge supports API tokens for private or merchant-specific integrations and OAuth 2.0 for applicable public applications, with scopes or permissions controlling access. | Martini can store tokens, OAuth credentials, scopes, and environment-specific settings as secure configuration and supply them in outbound requests. |
| File or attachment APIs | Not confirmed | Recharge’s core integration model is object- and JSON-oriented; a general file-import, attachment, or document API was not confirmed. | Martini can process external files when required, but the Recharge side should use a specifically documented capability rather than an assumed file endpoint. |
| Database or analytics access | No | Direct Recharge database access was not confirmed. Integrations should use Recharge APIs, webhooks, or documented exports where available. | Martini can write transformed Recharge data to supported downstream databases, but it should not depend on direct Recharge database connectivity. |
How Recharge exposes data and business events
Recharge REST APIs
Recharge’s versioned REST API is the primary interface for merchant, subscription, customer, order, charge, and product integrations. It supports collection retrieval, resource lookup, selected create or update operations, subscription lifecycle actions, and webhook management. API version and resource compatibility should be confirmed before implementation.
Martini implementation pattern
Martini implementation pattern: a workflow calls the current Recharge REST endpoint with credentials from secure configuration, processes the JSON response, follows pagination, maps the resource into a canonical model, and writes or publishes the result to downstream systems. For mutations, Martini validates the request, applies business rules, invokes Recharge, and records the outcome.
Implementation sequence
Recharge Storefront GraphQL API
Recharge provides a Storefront API based on GraphQL for supported storefront scenarios. This API is distinct from the merchant REST API and may expose different resources, permissions, and authentication requirements.
Martini implementation pattern
Martini implementation pattern: use GraphQL only when the required storefront operation is covered and the required credentials are available. A Martini workflow submits the query or mutation, validates the response and error structure, maps the selected fields, and keeps back-office operations on the REST API where appropriate.
Implementation sequence
Recharge Webhooks
Recharge supports webhook notifications for selected events involving resources such as Subscriptions, Orders, Charges, Customers, and Addresses. Available topics, payloads, delivery behavior, and API-version support must be checked against current Recharge documentation.
Martini implementation pattern
Martini implementation pattern: expose a controlled Martini API or workflow start trigger, verify the incoming request according to the current Recharge mechanism, persist an event or resource-based idempotency key, and route the event to an asynchronous workflow. The workflow retrieves current resource state when the webhook payload is incomplete and retries transient downstream failures.
Implementation sequence
Paginated Synchronization
Recharge REST collection endpoints support pagination, making page-by-page processing the appropriate pattern for initial loads and ongoing synchronization. A general-purpose bulk export API was not confirmed.
Martini implementation pattern
Martini implementation pattern: schedule a workflow, read a saved checkpoint, retrieve each Recharge page with controlled concurrency, normalize and write the results, and persist progress after successful processing. The workflow can use documented updated-time or status filters for incremental synchronization and can resume after a failure.
Implementation sequence
Common Recharge integration patterns
Pattern 1: Synchronize customers and subscriptions
When to use this pattern
Use this pattern when Salesforce, Shopify, a customer-service platform, or another downstream application needs current subscriber identity and lifecycle information. It separates initial historical loading from ongoing changes and does not assume that all resources fit in one response.
Integration direction
Example Mapping
| Recharge Field | Canonical Field | Target Field |
|---|---|---|
| Customer.id | customer.externalId | Salesforce Account.External_Id__c |
| Customer.email | customer.email | Salesforce Contact.Email |
| Subscription.status | subscription.lifecycleStatus | Salesforce Subscription Status |
| Subscription.next_charge_scheduled_at | subscription.nextChargeAt | Salesforce Next Charge Date |
Martini implementation pattern
A scheduler starts a paginated workflow that retrieves Customers, Addresses, and Subscriptions using a checkpoint and any documented incremental filters. Martini validates identifiers, maps the resources into a canonical model, distinguishes paused, cancelled, and expired states, and upserts the target records. Throttling and transient errors use controlled retries, while invalid records are isolated for review.
Martini capabilities used
- scheduling workflows
- API consumption
- pagination and checkpointing
- data mapping
- business rules
- error handling
Pattern 2: Process orders and charges for fulfillment and finance
When to use this pattern
Use this pattern when subscription-generated Orders and Charges must reach NetSuite, ShipStation, or another fulfillment or financial application. It is useful for normalizing customer, Address, line-item, discount, currency, and charge status data before creating downstream side effects.
Integration direction
Example Mapping
| Recharge Field | Canonical Field | Target Field |
|---|---|---|
| Order.id | order.externalId | NetSuite Sales Order External ID |
| Order.customer_id | customer.externalId | NetSuite Customer External ID |
| Order.shipping_address | shippingAddress | NetSuite Shipping Address |
| Charge.status | payment.status | NetSuite Payment Status |
Martini implementation pattern
Martini retrieves Orders and related Charges, enriches missing customer or Address details where needed, normalizes monetary values and currency precision, and applies fulfillment or accounting eligibility rules. The workflow writes to NetSuite with an idempotency key based on Recharge identifiers, records the result, and retries transient failures without duplicating orders or financial entries.
Martini capabilities used
- workflow orchestration
- REST API consumption
- data enrichment
- data mapping
- monetary normalization
- idempotency and retries
Pattern 3: Orchestrate Recharge webhook events
When to use this pattern
Use this pattern when downstream systems need near-real-time notification of selected subscription, order, charge, customer, or address changes. It is appropriate when Recharge provides a webhook topic for the required event, but it should not be treated as complete coverage of every lifecycle transition.
Integration direction
Example Mapping
| Recharge Field | Canonical Field | Target Field |
|---|---|---|
| event.topic | event.type | Klaviyo Event Name |
| customer.id | customer.externalId | Klaviyo Profile External ID |
| subscription.status | subscription.lifecycleStatus | Klaviyo Subscription Status |
| event.occurred_at | event.occurredAt | Klaviyo Event Timestamp |
Martini implementation pattern
A Martini API receives the Recharge webhook, validates it, checks a persisted event identifier, and starts an asynchronous workflow. The workflow enriches the event from Recharge when necessary, classifies the lifecycle change, maps it to the target event model, and sends it to Klaviyo. Duplicate deliveries return success without repeating the side effect, while delayed or out-of-order events are handled through current-state retrieval and retry logic.
Martini capabilities used
- API exposure
- webhook consumption
- workflow triggers
- event routing
- idempotency
- error handling
Pattern 4: Expose a controlled subscription API façade
When to use this pattern
Use this pattern when internal applications such as support tooling or commerce services need to request Recharge subscription changes without holding Recharge credentials or implementing Recharge-specific rules themselves.
Integration direction
Example Mapping
| Recharge Field | Canonical Field | Target Field |
|---|---|---|
| customerReference | customer.externalId | Recharge Customer ID |
| subscriptionAction | subscription.requestedAction | Recharge Subscription operation |
| requestedDate | subscription.effectiveDate | Recharge next-charge or scheduling field |
| requesterId | audit.actor | Martini audit context |
Martini implementation pattern
Martini exposes a secured API that authenticates the calling application, validates the requested action and subscription state, applies authorization and business rules, and invokes the appropriate Recharge REST endpoint. It returns a normalized response, records an audit context, and handles rate limits, rejected state transitions, and transient failures without exposing Recharge credentials to callers.
Martini capabilities used
- API exposure
- authentication and authorization
- business rules
- REST API consumption
- request validation
- audit and error handling
Applications commonly integrated with Recharge
Recharge commonly participates in subscription-commerce architectures alongside storefront, marketing, customer-service, ERP, and fulfillment applications. Martini can coordinate these systems through Recharge APIs and selected webhook events while keeping mappings, business rules, credentials, retries, and monitoring in a maintainable integration layer.
| Application | Scenario | Direction | Martini Pattern |
|---|---|---|---|
| Shopify | Synchronize subscription products, customers, orders, and storefront commerce data across the subscription and commerce platforms. | Recharge → Martini → Shopify | Use scheduled REST API workflows and selected webhook events to retrieve changed Recharge Customers, Products, Subscriptions, and Orders, normalize the payloads, and update Shopify. Apply idempotency and retry controls around order and subscription changes. |
| BigCommerce | Coordinate recurring subscription activity and customer or order data with a BigCommerce storefront. | Recharge → Martini → BigCommerce | Consume paginated Recharge REST resources in Martini workflows, map customer and order models to BigCommerce, and route supported lifecycle events through a webhook-triggered workflow. Use checkpoints for ongoing synchronization. |
| Klaviyo | Use subscription creation, renewal, cancellation, and customer activity to support lifecycle marketing and retention processes. | Recharge → Martini → Klaviyo | Receive selected Recharge webhook events or poll changed resources, validate subscription state, transform customer and lifecycle attributes, and send normalized data to Klaviyo through its supported API. Prevent duplicate profile or event updates with deterministic keys. |
| Gorgias | Give support agents visibility into subscription status and enable approved customer-service actions. | Recharge → Martini → Gorgias | Expose a controlled Martini API for Gorgias-facing operations, retrieve the relevant Recharge Customer, Address, or Subscription, apply authorization and state-transition rules, and return a normalized response. Route asynchronous updates through workflows where required. |
| NetSuite | Synchronize Customers, Orders, Charges, Products, revenue-related data, and fulfillment information with an ERP. | Recharge → Martini → NetSuite | Use scheduled or event-driven Martini workflows to retrieve Recharge Orders and Charges, normalize monetary values and customer addresses, apply accounting and fulfillment rules, and write the result to NetSuite. Checkpoint pages and retry transient API failures. |
| Salesforce | Share customer and subscription lifecycle data with account-management, service, and retention processes. | Recharge → Martini → Salesforce | Map Recharge Customers, Addresses, and Subscriptions to Salesforce objects through a canonical model. Use webhook events for selected changes, scheduled reconciliation for completeness, and business rules to distinguish paused, cancelled, and expired subscriptions. |
| Zendesk | Provide support teams with subscription, order, and charge context when handling customer cases. | Recharge → Martini → Zendesk | Retrieve the current Recharge context when a customer or ticket event occurs, transform it into Zendesk fields or metadata, and apply idempotent updates. Use a Martini API façade when support tooling needs controlled Recharge lookups. |
| ShipStation | Send subscription-generated orders for fulfillment and coordinate fulfillment or shipment status where supported. | Recharge → Martini → ShipStation | Process Recharge Orders and Addresses through a workflow, validate fulfillment eligibility, map line items and shipping details to ShipStation, and handle retries without creating duplicate shipments. Reconcile status changes through scheduled reads where necessary. |
How to build a Recharge integration in Martini
Objective
Establish the Recharge endpoint, API version, authentication model, and environment-specific configuration before building workflows.
Instructions in Martini
- Select the current Recharge API version required for the resources in scope
- Configure API tokens or OAuth 2.0 credentials in Martini environment configuration or secrets
- Define resource endpoints, scopes, and target-system credentials without embedding secrets in mappings
- Confirm whether the use case requires merchant REST or Storefront GraphQL access
Objective
Select an event-driven, API-led, or scheduled entry point based on the required freshness and Recharge event coverage.
Instructions in Martini
- Use a Martini API or workflow start trigger for selected Recharge webhooks
- Use a scheduler for initial loads, reconciliation, and incremental synchronization
- Use a controlled Martini API when internal applications need subscription operations
- Document the event topics and resource filters that are actually supported
Objective
Receive webhook data or retrieve current Recharge resources while accounting for pagination and incomplete event payloads.
Instructions in Martini
- Validate incoming webhook structure before processing
- Retrieve the current Customer, Address, Subscription, Order, Charge, or Product when enrichment is required
- Process collection endpoints page by page
- Persist a checkpoint for resumable synchronization
Objective
Coordinate calls, enrichment, routing, and asynchronous processing in a maintainable Martini workflow.
Instructions in Martini
- Separate webhook acknowledgment from longer downstream processing when appropriate
- Route resources by object type, lifecycle state, or target application
- Use controlled concurrency for large jobs
- Record correlation and idempotency identifiers across workflow steps
Objective
Transform Recharge JSON into canonical and target-specific models without passing vendor payloads directly through the enterprise landscape.
Instructions in Martini
- Map Customers, Addresses, Subscriptions, Orders, Charges, and Products explicitly
- Normalize dates, currency, decimals, discounts, taxes, and shipping values
- Validate required identifiers and target-specific fields
- Handle API-version fields and enumerations through explicit mappings
Objective
Apply subscription lifecycle, fulfillment, financial, authorization, and duplicate-prevention rules before side effects occur.
Instructions in Martini
- Distinguish paused, cancelled, and expired subscription states
- Check whether an order or charge has already been processed
- Validate authorized subscription actions before calling Recharge
- Handle delayed or out-of-order events by retrieving current state
Common Recharge data objects used in integrations
| Object | Typical Use | Common target systems | Martini handling |
|---|---|---|---|
| Customers | Subscriber and account-holder identity, contact details, and lifecycle information. | Shopify, Salesforce, Klaviyo, Gorgias, Zendesk, NetSuite | Martini retrieves or receives customer data, validates identifiers and contact fields, maps it to a canonical customer model, and applies upsert and duplicate-handling rules. |
| Addresses | Shipping and billing destinations associated with Customers and order fulfillment. | Shopify, BigCommerce, NetSuite, ShipStation, Zendesk | Martini normalizes address fields, associates the address with the correct Customer or Order, validates required shipping data, and handles changes independently from customer identity. |
| Subscriptions | Recurring arrangements containing products, frequency, status, and next-charge information. | Salesforce, Klaviyo, Gorgias, Shopify, BigCommerce | Martini maps subscription lifecycle states explicitly, distinguishes paused, cancelled, and expired states, and uses event or scheduled workflows with idempotent updates. |
| Orders | Orders generated from subscription charges or one-time purchases, including line and customer context. | NetSuite, Shopify, BigCommerce, ShipStation, Zendesk | Martini transforms order lines, customer and Address data, discounts, totals, and fulfillment attributes before writing to downstream systems and retrying transient failures. |
| Charges | Scheduled or processed billing events associated with Subscriptions and Orders. | NetSuite, Salesforce, Klaviyo, customer-service platforms | Martini maps charge status, amounts, currency, and related identifiers, applies monetary precision rules, and prevents duplicate financial side effects. |
| Products | Products and subscription products available for purchase. | Shopify, BigCommerce, NetSuite, Salesforce | Martini synchronizes product identifiers and attributes, validates catalog relationships, and routes unsupported or incomplete product data for review. |
Authentication and security considerations
Authentication options
Recharge supports API tokens for private or merchant-specific integrations and OAuth 2.0 for applicable public applications. Access scopes or permissions control which resources an application can read or modify.
Secure credential handling
Martini can store Recharge tokens, OAuth credentials, scopes, webhook verification settings, and environment-specific endpoints in secure configuration or secrets rather than workflow mappings or source-controlled templates.
Webhook protection
Validate incoming webhook requests using the current Recharge verification mechanism before processing them. Apply API authentication and authorization to any Martini façade that permits internal applications to request Recharge changes.
Operational considerations for Recharge integrations
Rate limits and pagination
Process Customers, Subscriptions, Orders, and Charges page by page. Use controlled concurrency, exponential backoff for throttling, and checkpoints for resumable jobs.
Idempotency and ordering
Webhook deliveries may be duplicated or delayed. Persist a stable event identifier or deterministic resource key before applying side effects, and retrieve current state when events arrive out of order.
Versions and schema changes
Record the Recharge API version in environment configuration and avoid mixing resource versions without confirming compatibility. Use explicit mappings and validation to detect new fields, changed enumerations, and deprecated fields.
Testing and monitoring
Test initial loads, incremental synchronization, subscription state transitions, rejected operations, throttling, duplicate events, and incomplete related resources. Monitor workflow logs and failed records separately from successful checkpoints.
Why use Martini instead of scripts or point-to-point integrations?
Centralized orchestration
Martini coordinates Recharge APIs, webhook triggers, downstream applications, databases, and messaging processes in workflows instead of scattering logic across scripts or point-to-point calls.
Maintainable transformation
Explicit mappings, validation, reusable services, and business rules keep Recharge-specific lifecycle and financial logic separate from target-system models.
Reliable operations
Checkpoints, retries, idempotency controls, error handling, secure configuration, and monitoring provide a consistent operating model for paginated synchronization and webhook processing.
Controlled access
Martini can expose a secured API façade so internal applications use governed operations without receiving Recharge credentials or duplicating subscription rules.
Frequently asked questions
Recharge can be integrated through its versioned REST API, selected Storefront GraphQL use cases, and webhooks for supported resource events. Enterprise workflows typically synchronize Customers, Addresses, Subscriptions, Orders, Charges, and Products using paginated requests, checkpoints, and explicit data mapping.
Yes. Martini can consume Recharge REST APIs, use the Storefront GraphQL API where the required use case and credentials are available, receive selected Recharge webhook events, map Recharge JSON, and expose controlled APIs for internal applications.
No. A dedicated Recharge connector is not required. Martini can integrate using Recharge’s confirmed native REST APIs, supported Storefront GraphQL API, webhook events, and token or OAuth authentication mechanisms.
Lonti does not charge an additional per-connector or per-vendor fee to integrate Recharge. The integration is subject to the provisioned capacity of the Martini environment. Separate costs may apply from Recharge, cloud infrastructure, or other third-party systems depending on subscriptions, usage, and deployment model.
Use the current Recharge REST API for typical merchant, customer, subscription, order, charge, and product workflows. Use the Storefront GraphQL API only for supported storefront scenarios with the appropriate authentication and resource coverage; it is not a replacement for all REST resources.
Yes. Martini can expose an API or use a workflow trigger to receive Recharge webhook requests. Recharge webhook coverage is selective, so the required topic, payload, delivery behavior, and API-version support should be verified before relying on an event.
Use scheduled paginated REST requests for initial and incremental synchronization, with checkpoints and documented updated-time or status filters where available. Martini can map Recharge JSON into canonical models, normalize monetary and lifecycle fields, and write the results to target applications.
Martini can apply rate-limit-aware retries, idempotency keys, validation, logging, and checkpoint recovery in workflows. It can also expose a secured API façade that validates internal requests, applies subscription business rules, calls Recharge, and returns normalized responses without distributing Recharge credentials.
Related Martini documentation
APIs
Build a reliable Recharge integration with Martini
Use Martini to connect Recharge subscription data and events with the applications, APIs, and operational systems that support your commerce business.