Connect Recharge to ChatGPT: Manage Recurring Billing and Customers
Learn how to connect Recharge to ChatGPT using a managed MCP server. Automate subscription lifecycles, manage recurring billing, and handle async batches.
If you need to connect Recharge to ChatGPT to automate subscription lifecycles, manage recurring billing, or orchestrate customer profiles, you need a Model Context Protocol (MCP) server. This server acts as the translation layer between ChatGPT's JSON-RPC tool calls and Recharge's complex REST APIs. You can either build, host, and maintain this infrastructure yourself, or use a managed integration platform like Truto to dynamically generate a secure, authenticated MCP server URL.
If your team uses Claude, check out our guide on connecting Recharge to Claude or explore our broader architectural overview on connecting Recharge to AI Agents.
Giving a Large Language Model (LLM) read and write access to a recurring billing platform like Recharge is a massive engineering challenge. You have to handle complex relational data payloads, map the nuanced differences between orders, charges, and subscriptions, and securely expose bulk operations. Every time you need a new workflow, a custom MCP server requires you to write, test, and deploy new tool definitions.
This guide breaks down exactly how to use Truto to generate a secure, managed MCP server for Recharge, connect it natively to ChatGPT, and execute complex billing workflows using natural language.
Stop writing boilerplate API integration code. Let Truto generate secure, managed MCP servers for your AI agents in seconds. :::
The Engineering Reality of the Recharge API
A custom MCP server is a self-hosted integration layer. While the open MCP standard provides a predictable way for models to discover tools, implementing it against Recharge's highly specific billing engine is exceptionally painful.
If you decide to build a custom MCP server for Recharge, you own the entire API lifecycle. Here are the specific integration challenges that break standard CRUD assumptions when working with Recharge:
The Triad of State: Subscriptions, Charges, and Orders
Recharge separates the concept of a subscription (the recurring contract) from a charge (the financial transaction) and an order (the fulfillment record). If an LLM is asked to "delay the customer's next shipment," your MCP server must understand context. Updating the next_charge_scheduled_at date on a Subscription resource might not stop a Charge that is already in a queued state for tomorrow. A naive CRUD tool implementation will result in AI agents updating the subscription but the customer still getting charged. Your tools must explicitly expose separate actions for skipping charges versus modifying subscription intervals.
Address-Bound Resource Architecture
In Recharge, subscriptions do not belong directly to a customer - they belong to an address. If an LLM needs to create a new subscription or move an existing one, it must first query or create the Address resource associated with the Customer. Building static MCP schemas for this requires creating multi-step orchestration logic so the LLM knows to resolve the address_id before attempting a subscription mutation.
Async Batches for Bulk Operations
When an LLM is tasked with "applying a 15% discount to all 500 active subscribers on the Gold plan," executing 500 synchronous API calls will immediately trip rate limits. Recharge solves this with Async Batches. You create a batch, append tasks to it, and submit it for processing. Exposing this to an LLM requires providing a suite of tools that the agent must string together: create the batch, add tasks, submit it, and poll for results. This is highly complex for an LLM to navigate without perfectly structured JSON schemas and tool descriptions.
How to Generate a Recharge MCP Server
Instead of building custom routing and token management, you can use Truto to generate an MCP server dynamically. The server is scoped to a specific integrated account and derives its tool definitions directly from Recharge's API documentation.
Method 1: Via the Truto UI
For teams who want a zero-code setup, you can generate the server directly from the dashboard:
- Navigate to the Integrated Accounts page and select your connected Recharge instance.
- Click the MCP Servers tab.
- Click Create MCP Server.
- Select your desired configuration (e.g., allow
readandwritemethods, filter by specific tags likesubscriptionsorcharges). - Copy the generated MCP server URL (it will look like
https://api.truto.one/mcp/<token>).
Method 2: Via the API
For platform engineers embedding this into an application, you can generate the MCP server programmatically. You need your $TRUTO_API_TOKEN and the $INTEGRATED_ACCOUNT_ID representing the connected Recharge store.
curl -X POST https://api.truto.one/integrated-account/$INTEGRATED_ACCOUNT_ID/mcp \
-H "Authorization: Bearer $TRUTO_API_TOKEN" \
-H "Content-Type: application/json" \
-d '{
"name": "Recharge Billing Ops Agent",
"config": {
"methods": ["read", "write", "custom"],
"tags": ["subscriptions", "charges", "customers", "async_batches"]
}
}'The response contains the secure URL:
{
"id": "mcp_abc123",
"name": "Recharge Billing Ops Agent",
"url": "https://api.truto.one/mcp/a1b2c3d4e5f6..."
}A critical note on rate limits: Truto does not retry, throttle, or apply backoff on rate limit errors. When the upstream Recharge API returns an HTTP 429, Truto passes that error directly back to the calling client. Truto normalizes the upstream rate limit info into standardized headers (ratelimit-limit, ratelimit-remaining, ratelimit-reset) per the IETF spec. The caller (or the AI framework) is strictly responsible for inspecting these headers and implementing retry/backoff logic.
How to Connect the MCP Server to ChatGPT
Once you have the Truto MCP URL, connecting it to ChatGPT takes seconds. The URL acts as the router, authentication token, and schema registry all at once.
Method A: Via the ChatGPT UI
If you are using ChatGPT Pro, Plus, Business, Enterprise, or Education:
- In ChatGPT, navigate to Settings -> Apps -> Advanced settings.
- Enable the Developer mode toggle.
- Under MCP servers / Custom connectors, click Add.
- Name the connection (e.g., "Recharge Billing").
- Paste the Truto MCP URL into the Server URL field and click Add.
ChatGPT will immediately perform an initialization handshake, discover the available Recharge tools, and register them for use.
Method B: Via Manual Config File (SSE)
If you are running a local agent, Claude Desktop, or a framework that requires a configuration file, you can map the URL using the official Server-Sent Events (SSE) transport adapter provided by the MCP specification.
{
"mcpServers": {
"recharge-billing": {
"command": "npx",
"args": [
"-y",
"@modelcontextprotocol/server-sse",
"--url",
"https://api.truto.one/mcp/a1b2c3d4e5f6..."
]
}
}
}Hero Tools for Recharge
Truto automatically generates descriptive, highly-typed tools for the Recharge API based on the integration's configuration. The query parameters and body payloads share a flat input namespace, simplifying how the LLM passes arguments.
Here are the highest-leverage operations for automating billing workflows.
list_all_recharge_subscriptions
Retrieves a list of subscriptions, filterable by address, customer, status, or date ranges. Essential for finding the exact subscription_id an agent needs to mutate.
Usage note: Always instruct the agent to filter by customer_id or email if known, to avoid pulling massive paginated lists.
"Look up all active subscriptions for customer ID 987654. I need to know their current order interval and the next scheduled charge date."
update_a_recharge_subscription_by_id
Modifies an existing subscription. This tool is used to change pricing, swap products (via variant IDs), or adjust delivery frequencies.
Usage note: Updating interval parameters forces a recalculation of the next_charge_scheduled_at date. If updating intervals, the charge_interval_frequency, order_interval_frequency, and order_interval_unit must all be provided together.
"Update subscription 123456. Change the order interval frequency to 60 days, and make sure the order interval unit is set to days."
recharge_subscriptions_cancel
Cancels an active subscription immediately. Requires a cancellation reason.
Usage note: Canceling a subscription does not automatically refund past charges. It only prevents future charges from generating.
"Cancel subscription 998877. The cancellation reason is 'Too expensive', and add a comment saying the user requested this via the support chatbot."
recharge_charges_skip
Skips a queued Recharge charge and reschedules the associated subscriptions to the next future date based on their interval.
Usage note: This acts on the charge_id, not the subscription directly. This is the correct operational tool to use when a customer asks to "skip this month's delivery."
"Find the queued charge for subscription 112233 scheduled for next week, and skip it so they don't get a delivery this month."
recharge_charges_refund
Refunds a processed Recharge charge either in full or partially.
Usage note: Refunds cannot exceed the original total price. The agent must pass the charge_id.
"Issue a full refund for charge ID 445566. The customer reported the package arrived damaged."
create_a_recharge_async_batch
Initializes a new async batch for bulk operations (like updating multiple discounts or prices at once).
Usage note: This tool only creates the batch container. Tasks are not attempted until the batch is submitted via the process tool.
"Create a new async batch for a 'discount_create' operation. Return the batch ID so we can start appending tasks to it."
recharge_async_batches_process
Submits an existing async batch for execution.
Usage note: Batches process quickly and dispatch webhooks at a high rate. The agent must pass the async_batche_id.
"Submit async batch ID 778899 for processing, and let me know when it moves to the submitted status."
For the complete tool inventory, including payload schemas for checkouts, addresses, and onetime products, view the Recharge integration page.
Workflows in Action
Exposing individual tools is only half the battle. The real power of an MCP server is enabling the LLM to orchestrate multi-step billing operations autonomously.
Scenario 1: The Subscription Reschedule & Interval Swap
Customer support chatbots frequently handle requests to change delivery cadences and skip immediate orders.
"The customer with email jane@example.com is going on vacation. Skip her next upcoming delivery, and change her ongoing subscription delivery frequency from every 30 days to every 60 days."
How the agent executes this:
- Calls
list_all_recharge_customerswith the email to retrieve thecustomer_id. - Calls
list_all_recharge_subscriptionsfiltered by thecustomer_idto find the active subscription ID. - Calls
list_all_recharge_chargesfiltered by the subscription ID and statusqueuedto find the upcoming charge. - Calls
recharge_charges_skipwith thecharge_idto safely skip the vacation month's order. - Calls
update_a_recharge_subscription_by_idpassingorder_interval_frequency: 60andcharge_interval_frequency: 60to adjust the permanent cadence.
sequenceDiagram
participant User as ChatGPT (Agent)
participant MCP as Truto MCP Server
participant Recharge as Recharge API
User->>MCP: list_all_recharge_customers(email: jane@...)
MCP->>Recharge: GET /customers?email=jane@...
Recharge-->>MCP: Customer ID: 101
MCP-->>User: Returns Customer Data
User->>MCP: list_all_recharge_subscriptions(customer_id: 101)
MCP->>Recharge: GET /subscriptions?customer_id=101
Recharge-->>MCP: Subscription ID: 505
MCP-->>User: Returns Subscription Data
User->>MCP: recharge_charges_skip(charge_id: 909)
MCP->>Recharge: POST /charges/909/skip
Recharge-->>MCP: 200 OK
MCP-->>User: Returns Success
User->>MCP: update_a_recharge_subscription_by_id(id: 505, frequency: 60)
MCP->>Recharge: PUT /subscriptions/505
Recharge-->>MCP: 200 OK
MCP-->>User: Returns Updated SubscriptionScenario 2: Bulk Discount Processing
A marketing operations manager needs to apply a discount code to a specific cohort of subscribers without triggering rate limits.
"I need to apply the discount code 'SUMMER2026' to these three subscription IDs: 111, 222, and 333. Use an async batch to process this safely."
How the agent executes this:
- Calls
create_a_recharge_async_batchwithbatch_type: discount_create. - The agent realizes (via the tool schema) it needs to append tasks. (If a specific append tool is exposed, it calls it iteratively for 111, 222, 333).
- Calls
recharge_async_batches_processwith the generatedbatch_idto queue the execution on Recharge's backend. - Calls
get_single_recharge_async_batch_by_idto verify thestatusmoved tosubmitted.
The agent handles the entire orchestration of the bulk pipeline using the native API mechanics defined in the MCP schemas.
Security and Access Control
Giving an AI agent access to an enterprise billing platform requires strict security boundaries. Truto's MCP servers provide four layers of access control out of the box:
- Method Filtering: Configure the server with
config.methods: ["read"]to allow onlyGETandLISToperations. This completely sandboxes the agent from modifying subscriptions or issuing refunds. - Tag Filtering: Restrict the AI's blast radius by applying tags. Setting
config.tags: ["subscriptions", "customers"]prevents the agent from discovering or calling tools related tocharges,discounts, orwebhooks. - Require API Token Auth: By default, the generated URL acts as a bearer token. If you set
require_api_token_auth: true, the connecting client (e.g., your custom LangGraph runtime) must also provide a valid Truto API token in theAuthorizationheader, adding a secondary identity check. - Expiration (TTL): Set an
expires_atISO datetime when creating the MCP server. The token and KV storage will auto-destruct when the time is reached, perfect for temporary diagnostic sessions.
Ditching the Boilerplate for Billing Operations
Building a custom MCP server for Recharge means you are responsible for maintaining schemas, handling paginated cursors, and adapting to upstream API deprecations. Every time your Operations team wants the AI agent to execute a new workflow - like merging addresses or tracking credit accounts - a developer has to write and test the integration code.
By leveraging Truto's dynamically generated MCP servers, you eliminate the integration codebase entirely. The LLM connects to a self-contained, authenticated URL that automatically translates natural language into precise, schema-validated JSON-RPC calls against the Recharge API.
Your engineers can stop reading billing API documentation, and your AI agents can start orchestrating revenue lifecycles today.
FAQ
- How does the ChatGPT MCP server handle Recharge API rate limits?
- Truto passes upstream Recharge HTTP 429 rate limit errors directly to the client. It normalizes this data into standard IETF headers (ratelimit-limit, ratelimit-remaining, ratelimit-reset), meaning your AI framework or client application must implement its own retry and backoff logic.
- Can I limit the ChatGPT AI agent to read-only access for Recharge?
- Yes. When generating the MCP server URL, you can pass a configuration object with `methods: ["read"]`. This ensures the AI agent can only execute GET or LIST operations, completely blocking POST, PUT, PATCH, and DELETE requests.
- Does this integration support bulk updates for Recharge subscriptions?
- Yes. The MCP server exposes Recharge's Async Batch API endpoints. The AI agent can create an async batch, submit it for processing, and poll the tasks to handle bulk operations like applying discounts across hundreds of subscriptions.
- How do I secure the MCP server if the URL is exposed?
- By default, the tokenized URL acts as authentication. For higher security, you can enable `require_api_token_auth` during creation, which forces the connecting client to also pass a valid Truto API token in the Authorization header.