As Amazon EVS prepared its public API for general availability, I helped align a set of API exceptions with the behavior that actually triggered them. The work used standards-aligned exceptions and clear deprecation guidance instead of removing API surface before launch, keeping the API backward compatible through its public debut. This is one example of the upstream API work in Design Influence and Upstream Collaboration.
The challenge
A few of the API’s exceptions had names that did not match the conditions that raised them. TooManyTagsException was returned when a customer exceeded an EVS service quota, and TagPolicyException was returned for invalid inputs on environment operations. The names pointed toward tags and IAM policies, while the real conditions are a service quota and input validation.
That mismatch was visible in the public reference and created a developer-experience problem: the exception name did not clearly tell developers what they needed to fix. Because public AWS APIs stay backward compatible for the life of the service, the team needed to correct the error surface before general availability without creating unnecessary friction for customers.
The team considered deprecating and removing the mismatched exceptions while the API was still pre-GA.
Aligning the error surface with behavior
I pushed back on removing the mismatched exceptions outright because that path created backward-compatibility and customer-trust risk. Rather than choose a replacement pattern by preference, I recommended bringing the question to a senior API-design reviewer who could ground the decision in AWS standards and identify the cleanest path forward.
The review supported a standards-aligned path: introduce ServiceQuotaExceededException and ValidationException, keep the older exceptions for compatibility, and document the transition clearly. I drafted the deprecation guidance and recommended the precise term deprecated, since softer language would leave developers unsure whether the old exception still applied.
What this demonstrates
- Treating an API’s error surface as a developer-experience surface in its own right
- Applying AWS API design standards and backward-compatibility constraints before launch
- Using senior API-design review to ground a product decision in standards, not preference
- Writing precise deprecation guidance that tells developers exactly what changed and what to use instead
- Classifying API errors where developers are most likely to look for them
Outcomes
Developers who hit quota or validation failures now see exceptions that accurately describe the condition they need to fix. The older exceptions remain documented with clear deprecation guidance that points to the standards-aligned replacements. The change shipped without removing API surface or delaying general availability, and the final exception model is visible in the public EVS API reference.
Live documentation
- ServiceQuotaExceededException (archived snapshot)
- ValidationException (archived snapshot)
- TooManyTagsException — legacy, with deprecation guidance (archived snapshot)
- TagPolicyException — legacy, with deprecation guidance (archived snapshot)