Skip to content

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.

Roopendra Talekar Roopendra Talekar · · 9 min read
Connect Recharge to ChatGPT: Manage Recurring Billing and Customers

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:

  1. Navigate to the Integrated Accounts page and select your connected Recharge instance.
  2. Click the MCP Servers tab.
  3. Click Create MCP Server.
  4. Select your desired configuration (e.g., allow read and write methods, filter by specific tags like subscriptions or charges).
  5. 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:

  1. In ChatGPT, navigate to Settings -> Apps -> Advanced settings.
  2. Enable the Developer mode toggle.
  3. Under MCP servers / Custom connectors, click Add.
  4. Name the connection (e.g., "Recharge Billing").
  5. 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:

  1. Calls list_all_recharge_customers with the email to retrieve the customer_id.
  2. Calls list_all_recharge_subscriptions filtered by the customer_id to find the active subscription ID.
  3. Calls list_all_recharge_charges filtered by the subscription ID and status queued to find the upcoming charge.
  4. Calls recharge_charges_skip with the charge_id to safely skip the vacation month's order.
  5. Calls update_a_recharge_subscription_by_id passing order_interval_frequency: 60 and charge_interval_frequency: 60 to 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 Subscription

Scenario 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:

  1. Calls create_a_recharge_async_batch with batch_type: discount_create.
  2. 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).
  3. Calls recharge_async_batches_process with the generated batch_id to queue the execution on Recharge's backend.
  4. Calls get_single_recharge_async_batch_by_id to verify the status moved to submitted.

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 only GET and LIST operations. 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 to charges, discounts, or webhooks.
  • 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 the Authorization header, adding a secondary identity check.
  • Expiration (TTL): Set an expires_at ISO 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.

More from our Blog