Our product has a genuinely nice feature: when a cloud provider breaches its SLA, we automatically file the support ticket to claim your credits. You’re owed money; we go get it for you. No human has to log into a portal and rage-fill a form. Delightful.

Then we met InvalidSupportPlan.

The premise

To file any support ticket through the Azure Support API — including a billing ticket, including the very “you breached your SLA, please refund me” ticket — you need a paid support plan (Developer tier or above). On Free or Basic, the API doesn’t just reject SLA tickets. It rejects all ticket creation, full stop:

InvalidSupportPlan: The subscription does not have a support plan
that allows creating support tickets via the API.

Sit with the logic for a second. The SLA breach is Azure’s fault. The remedy for Azure’s fault is a credit. To request the credit programmatically, you must first be paying Azure extra for a support plan. To complain about the service, you must purchase the complaints department.

It’s a velvet rope in front of the suggestion box.

Why this is funny and a real architecture problem

The comedy is that the gate sits in front of the one ticket type you’d think they’d want you to file easily — the billing one. The engineering problem is that we built an automated filing pipeline on top of an API whose front door is locked for exactly the customers most likely to be cost-sensitive (the ones on Free/Basic, watching every dollar — i.e. our core audience).

You can’t code your way around it. There’s no clever retry, no alternate endpoint, no header that whispers the magic word. The capability is entitlement-gated upstream, outside your code entirely. The API is behaving as designed; the design is just funny.

What we did about it

You can’t fix someone else’s pricing model, so you fix the expectations and the failure mode:

  1. Detect the entitlement before promising the feature. Don’t let a customer onboard into “automated SLA claims” if their subscription can’t create tickets. Check the support plan up front and tell them plainly.
  2. Fail loud and human, not silent. A breach that can’t be auto-filed should surface as “we found a claimable breach worth $X — but your Azure plan blocks automated filing; here’s how to claim it manually,” not a swallowed InvalidSupportPlan in a worker log.
  3. Write it down where future-you will look. This is a permanent, external constraint, not a bug to be fixed — so it lives in our memory notes, flagged as “this will never work on Free/Basic, stop trying.”

The moral

  • Some “bugs” are policies. When an API returns the same error no matter how you call it, stop debugging your request and go read the entitlement docs.
  • A feature built on a third-party capability inherits that third party’s gates. Map them before you promise the feature, not when a customer hits the wall.
  • The kindest thing you can do with an immovable external constraint is detect it early and explain it clearly. Nobody enjoys discovering the complaints department is behind a paywall after something already broke.

Azure SLA credits: real, claimable, and — on the cheap plans — strictly artisanal, hand-crafted by a human.

Amit Jethva is the CTO and co-founder of Nuvika Technologies Pvt Ltd, makers of Fintropy, a multi-cloud FinOps platform. Learn more at nuvikatech.com.