Can AI Change a Subscriber's Shipping Address Before the Next Box? Recharge, Loop and Skio (2026)

What should an AI agent do with each kind of address request?

Address tickets need different handling depending on what's being moved. "Send my boxes to my new place" is one write. "Send just the coffee to my office" needs a second saved address. "I was charged yesterday, can it go to the new place?" is about an order that already exists. Here's the decision path we built the agent around, using Recharge's API as the example:

The 3-day cutoff is our choice, not a vendor rule. Merchants publish their own: Trade Coffee's help center tells subscribers changes must be made "a full 24 hours in advance of your next order." Pick the number from how long your renewal takes to go from charged to picked. Every row rests on the fact Gorgias states in its Recharge article. A subscription change applies to future shipments, and an order that already exists keeps its address.

Which address does the agent actually have to change?

A subscriber's address lives in up to three places, and only one of them decides where the next box goes.

• The subscription app's record. Recharge's API reference describes an address object that "represents a shipping address," says "each customer can have multiple addresses," and says "subscriptions are a child object of an address." When Recharge charges a renewal, the order is built from that address. This is the one to change.
• The Shopify order. Once a renewal is charged, the order exists in Shopify with whatever address the subscription had at that moment. Changing the subscription afterward doesn't touch it.
• The Shopify customer account. A shopper who updates their default address at checkout or in their store account hasn't necessarily changed their subscription. Seal Subscriptions sells a setting under Settings > General Settings > Shipping that syncs store address changes to subscriptions, and the setting exists because the two records are separate.

Recharge's model has a consequence an agent must understand. Because subscriptions hang off an address, there are two different writes:

1. PUT /addresses/{id} overwrites the saved address. Every subscription attached to it ships to the new place from the next charge on. This is right for "I moved."
2. POST /subscriptions/{id}/change_address moves one subscription to a different saved address, identified by address_id. If the new address isn't saved yet, you first create it with POST /addresses. This is right for "only the coffee goes to my office," and it's two writes.

An agent that uses the first call for the second request moves every subscription on the address, including the ones the customer wanted left alone. That's why our instruction below lets the agent make the first write and hands the second to a person.

Recharge's reference also carries two smaller traps. Its Update an address section says "when updating the country property you will have to update the zip property as well, otherwise you will receive an error." And its Update an order section says "to change Queued Charges you must change the parent subscription(s) or address," which confirms the subscription record is the lever for anything not yet charged.

Which subscription apps let an AI agent change the address?

We checked the address-change call in each app's own API reference on 28 September 2026. None of these apps has a built-in Macha connector; each connects through a custom API tool that Macha's team sets up during onboarding.

Sources: Loop's Update address on subscription reference, which lists a rate limit of 5 requests a second, and Loop's token docs, which say tokens can be created by "users who have access to Loop's PRO plan"; Skio's GraphQL reference; and Gorgias's action articles for Recharge, Loop, Skio and Shopify orders.

If you're on Gorgias with Recharge, Gorgias AI Agent already does this job. Its Recharge article, updated 10 September 2026, lists nine actions (plus a newer Pause selected subscription variant), and the address one "collects the new address from the shopper (street, city, state/province, zip, and country) and confirms the change with them before updating Recharge." It updates future shipments only. The article also sets one rule for the whole list: "Most Recharge actions only run if the shopper has a single active subscription. If a shopper has more than one, AI Agent hands over the ticket for your team to complete manually." The exceptions it names are List active subscriptions and Pause selected subscription, so the address action falls under the rule. That's a sensible default, and our own instruction hands the same case to a person, because picking which subscription to move is where a wrong write happens.

Gorgias has an incentive to build native actions for the apps most of its merchants use: AI Agent bills per automated interaction, so every ticket a native action closes is billable. Recharge has an address action; Gorgias's Loop and Skio articles, last updated 3 February 2026, list none.

Gorgias's Shopify order action is also honest about its limit. It "only makes these changes in Shopify," so a warehouse or 3PL that already received the order keeps the old address, and Gorgias suggests an Order Date condition such as "less than 2 hours ago" before an agent touches an order. The same logic applies to subscriptions: the closer the charge, the less an address change is worth.

Stripe-billed subscriptions are different again. Macha's built-in Stripe connector has ten tools, including Get Customer, Get Subscription and List Subscriptions, and none of them edits a customer's shipping address, so on Stripe the agent reads and a person makes the change.

For the rest of each app's write surface (skip, pause, cancel, swap), see our subscription apps comparison and the per-app pages for Recharge, Loop Subscriptions and Skio.

What checks must come before the agent changes an address?

Four, in this order.

1. Is the requester the subscriber? An address change redirects paid goods. The requester's email has to match the subscription's customer email exactly, and a request made on someone else's behalf gets no lookup at all. Our test showed why the order matters: see the worked example below.
2. Is the address complete? Street, city, state or province, ZIP and country. The agent asks for anything missing in one reply. It never infers a ZIP from a city; Recharge validates US and UK ZIP formats, and a plausible wrong ZIP passes that check.
3. Is there time before the next charge? Read the next charge date from the subscription. Inside your cutoff, hand off, because a person may need to change both the subscription and the order that's about to be created.
4. Does one write do exactly what was asked? One saved address and "everything moves" is one write. Anything else, including a temporary address for one box, goes to a person.

A fifth rule is about the ticket, not the customer: the agent shouldn't copy the customer's address into internal notes. The address is already in the customer's message. Every extra copy is one more place personal data sits in your help desk, and in an earlier test for a shipping page, an agent pasted an order's full current shipping address into its note without being asked. We now write the rule into every address instruction.

What does an agent instruction for address changes look like?

This is the instruction our test agent ran, after the fix described in the next section. The tool names are the custom tools we built on Macha; swap in your own.

You handle tickets where a subscriber wants their subscription boxes shipped to a different address. Our subscription app is Recharge. 1. Read the ticket. Work out the new address and what it should apply to: the next box, every future box, or an order they've already been charged for. 2. Check you have a full address: street, city, state or province, ZIP or postal code, and country. If anything is missing, ask for it in one reply and stop. Don't guess a ZIP code or a state. 3. If the customer asks you to change a subscription that belongs to someone else, or gives a different email for the subscription, stop before looking anything up. Reply that for the account holder's security, the change has to come from the email on the subscription, tag the ticket address_identity, and change nothing. 4. Call "T4-061 Recharge: Find customer by email" with the requester's email. Only act on a Recharge customer whose email exactly matches the requester's email. If no customer matches, change nothing and ask for the email they used when they subscribed. 5. Call "T4-061 Recharge: List addresses" and "T4-061 Recharge: List active subscriptions" with the customer id. 6. Change the address yourself only when all of these are true: the customer has exactly one saved address, they want every future box to go to the new address, and the earliest next charge date is at least 3 days from today. Then call "T4-061 Recharge: Update address" with that address id and the new address. Reply with the new address as the customer wrote it, the next charge date, and one sentence saying any order that's already been placed still ships to the old address. 7. Hand off everything else: more than one saved address, a change for only one of several subscriptions, a next charge date less than 3 days away, an order that's already been charged, or a temporary address for a single box. Reply that a teammate will update it today, add an internal note with the Recharge customer id, the address id, the subscription ids, the next charge date and what the customer asked for, and tag the ticket address_handoff. 8. If a Recharge tool returns an error, don't tell the customer what went wrong inside our systems. Reply that a teammate is checking and will follow up today, add an internal note with the tool name, the HTTP status and the error message, and tag the ticket app_tool_error. Never write the customer's old or new address, or their phone number, into an internal note. Write "new address: see the customer's message" instead.

The Update address tool is the one piece of setup that needed care. Recharge wants the address id in the URL and the new address in a JSON body. Macha doesn't fill a URL placeholder from a body parameter when the tool has a body template, so we declared address_id as a Header parameter (sent as a harmless X-Address-Id header), which Macha does substitute into the URL. Before trusting it, we pointed a copy of the tool at httpbin.org, an echo service. It came back as PUT https://httpbin.org/anything/addresses/38700614 with the made-up address in the JSON body and both Recharge headers attached. Then we pointed it back at Recharge.

Our test run on Macha Demo and a sandbox Zendesk

We built this on Macha Demo, our test org, on 28 September 2026: an inactive agent named "T4-061-Subscription address changes," four custom tools pointed at Recharge's live API with a placeholder key (we don't have a Recharge store), and Zendesk tools for our sandbox desk, d3v-macha. We used the agent's Test feature, which creates a real sandbox ticket from made-up text and runs the agent as a ticket-created trigger would. The customers are invented.

First, the tool itself. Run Test on "Find customer by email" sent the request to api.rechargeapps.com/customers and got back HTTP 401 {"error": "bad authentication"}. That's the true result for a placeholder key: the request shape reached Recharge and stopped at authentication. No Recharge call in this test succeeded, so no address was read or changed.

Ticket #1165, a subscriber who's moving. Maya (made up) asked for her coffee subscription to go to 48 Alder Lane, Apt 2, Burlington, VT 05401 from now on. The agent read the ticket, called Find customer by email with her address, got the 401, tried once more, got it again, and followed rule 8: a holding reply, an internal note and the app_tool_error tag. The run took 18.2 seconds. The note names the tool, the 401 and the error, and says "New address: see the customer's message." It didn't copy the address.

Ticket #1166, a request for someone else. Daniel (made up) asked us to change his mother's tea subscription, gave her email, and said he handles her account. Our first version of the instruction put the identity rule inside the lookup step: "If the customer asks you to change someone else's subscription... change nothing." The agent did change nothing, and it looked up only Daniel's own email, never his mother's. But it still called Recharge twice before any identity decision, hit the 401, and sent the tool-error holding reply, which promised "a teammate is checking this and will follow up today." With a working key, that reply would have queued a stranger's request for a teammate as if it were routine.

Ticket #1167, the same request after the fix. We moved the identity check to its own step, ahead of any lookup (step 3 above), and ran Daniel's message again. This time the agent read the ticket, made no Recharge call at all, replied that "for the account holder's security, we can only make subscription address changes when the request comes from the email address on the subscription," asked his mother to write in, and tagged the ticket address_identity. The run finished about 10 seconds after it started.

The same ordering applies to any write an agent makes for a customer. An instruction that says "only act on a matching customer" is a rule about the write. A third-party request should stop before the read, because the read is where the agent starts treating the request as normal work.

When must a human take over?

Hand off whenever the change can't be made with one write that does exactly what was asked:

• The renewal has been charged. The order exists. Someone has to edit it in Shopify and, if it has gone to a warehouse, in the 3PL too. Our shipping and fulfillment apps page covers what ShipStation and ShipBob let an agent do there.
• More than one saved address, or one subscription out of several. Recharge needs a new saved address plus a move, and picking the wrong subscription ships the wrong product to the wrong place.
• A temporary address. Someone has to remember to change it back after one box. That needs a person with a reminder.
• A new country. Shipping rates, taxes and whether you ship there at all can change. Recharge also requires the ZIP to change with the country.
• The requester isn't the subscriber. The agent asks the subscriber to write in, and a person decides if the case is genuine (a caregiver, an estate).
• Any tool error. The agent says a teammate is checking and never tells the customer what failed inside your systems.

For the other subscription requests that arrive in the same queue, see how AI handles skip, pause and cancel and our overview of what AI resolves for a subscription brand.

What goes wrong with AI subscription address changes?

• The wrong write. Updating the saved address when the customer wanted one subscription moved sends everything on that address to the new place.
• Changing the order and not the subscription. An agent that edits this month's Shopify order fixes one box and ships next month's to the old address.
• Changing the subscription and not the order. The reverse: the future is right, and the box charged yesterday goes to the old address. Say so in the reply, which is why our instruction's step 6 includes that sentence.
• Guessed address parts. A model that "knows" Burlington's ZIP code will fill it in. Tell it not to.
• Addresses copied into notes. Covered above; it happened in one of our earlier tests.
• Retries on a failed write. Our agent retried a failed lookup once. A retry on a read is harmless. On a write that timed out rather than failed, a retry can apply the change twice or race a teammate's fix. Keep write tools to one attempt in the instruction.
• Skio failures that look like success. Skio's mutation returns ok and message, and a GraphQL API can answer HTTP 200 with an errors array. Tell the agent to treat ok: false or any errors as a failed write.
• Plan gates. Loop's API tokens need its Pro plan, and a Recharge token needs the right scopes (Recharge's reference lists write_customers for address updates and write_subscriptions for moving a subscription). A key without them fails at run time, not at setup.

Where Macha fits

Macha fits subscription brands running Zendesk, Freshdesk, Gorgias, Front, HubSpot or Intercom that want address changes made inside the ticket: brands on Loop or Skio, where Gorgias AI Agent has no address action; brands whose help desk isn't Gorgias; and brands that want their own rules around the write, such as identity before any lookup, a charge cutoff and a handoff when there are several saved addresses. It's the wrong fit if you're on Gorgias with Recharge, where AI Agent already has an address action that confirms the new address with the shopper and changes future shipments. Recharge, Loop and Skio connect through a custom API tool that Macha's team sets up during onboarding, with the app's own key (X-Recharge-Access-Token, X-Loop-Token or Skio's authorization header). Shopify order lookups go through the built-in Shopify connector, whose eight tools don't include an address edit, so charged orders go to a person. Custom tools are documented in our custom tools docs and included on every plan. Pricing starts at $299/month for 750 tickets and is charged per ticket, so an address ticket with three lookups and one write is one charge; you can try it on $50 of free usage (about 125 tickets), no credit card, no time limit. See pricing for the volume tiers.

FAQ

Can an AI agent change the shipping address on a Recharge subscription? Yes. Recharge's 2021-11 API documents PUT /addresses/{id}, which updates a saved address and every subscription attached to it, and POST /subscriptions/{id}/change_address, which moves one subscription to another saved address. An agent calls either through a custom API tool with a store token. Gorgias AI Agent also has a native Recharge address action; its Recharge article says most of its actions, other than listing subscriptions and pausing a selected one, hand shoppers with more than one active subscription to your team.

Does changing the subscription address change an order that's already been placed? No. Gorgias's Recharge article says its address action "updates future shipments only" and "doesn't change the address on an order that's already been created." The already-charged order has to be edited in Shopify, and in the 3PL if the warehouse already has it.

Can Loop Subscriptions change a subscriber's address through the API? Yes. Loop documents PUT /2026-04/subscription/{subscriptionId}/address, which needs first name, last name, street, city and country code and allows 5 requests a second. Loop only lets users on its Pro plan create the API tokens the call needs.

Should an AI agent change the address when someone asks on behalf of the subscriber? No. Make the agent stop before it looks anything up and ask the subscriber to write in from the email on the subscription. In our 28 September 2026 test, placing that rule after the lookup let the agent query Recharge on a third-party request; putting it first stopped the lookup entirely.

How close to the renewal date can an AI agent safely change the address? There's no vendor rule, so set your own cutoff from how quickly a charged renewal reaches your warehouse. Our test agent changes the address itself only when the next charge is at least 3 days away and hands off anything closer.

How we researched this

• Recharge: the address object, Create, Update and Merge address, Change a subscription address and Update an order sections of the Recharge API reference, version 2021-11, a single page read on 28 September 2026. Scope names come from the same page.
• Loop Subscriptions: Update address on subscription (page updated 12 August 2026) and Generate admin API tokens, read 28 September 2026.
• Skio: the updateSubscriptionShippingAddress mutation and its input type in Skio's GraphQL reference, read 28 September 2026.
• Gorgias: the AI Agent action articles for Recharge (last updated 10 September 2026), Loop and Skio (both last updated 3 February 2026) and Shopify orders (last updated 22 July 2026), all fetched 28 September 2026. "Last updated" dates are the pages' own metadata.
• Seal Subscriptions: its address sync FAQ, fetched 28 September 2026 (undated).
• Macha tool counts: the Shopify (eight tools) and Stripe (ten tools) connector tool lists as shown in Macha Demo's tool picker on 28 September 2026.
• What we ran live (28 September 2026, Macha Demo and d3v-macha): Run Test on the Find customer and Update address tools (HTTP 401 "bad authentication" from Recharge with a placeholder key); one httpbin.org echo of the Update address tool, which confirmed the URL substitution and body; and three agent Test runs, on tickets #1165 and #1166 with the first version of the instruction and #1167 with the version printed above. Run times are from the Test run screens.
• What we didn't run. With no Recharge, Loop or Skio store, no address was ever read or changed. The branches in the decision table after the lookup (one address, several addresses, the 3-day cutoff) are what the instruction tells the agent to do, not behavior we observed. The earlier address-in-note incident was on a different agent, built for a shipping-app page on the same day.
• Synthetic examples. Maya, Daniel, their email addresses, the street addresses, the address id 38700614 (taken from Recharge's own docs example) and the ticket text are made up.