# To File a Complaint, You Must First Pay for the Privilege of Complaining

_Azure's `InvalidSupportPlan`, and the beautiful absurdity of automated SLA claims._

June 11, 2026 · 3 min · Amit Jethva

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](https://www.nuvikatech.com/Fintropy_Overview.html), a multi-cloud FinOps platform. Learn more at [nuvikatech.com](https://www.nuvikatech.com)._