Postman Contract Testing Checklist for API Changes
Review a proposed API change for breaking effects.
The Open buttons send the prompt text as currently shown below to that site only when you click. Fill in the placeholders first.
[VERIFY] is an editorial flag, not a blank to fill. Wherever the prompt shows [VERIFY], check that item against a reliable source before you use it.
Review a proposed API change. Current contract (fields, types, status codes): [CURRENT_CONTRACT]. Proposed change: [PROPOSED_CHANGE]. Known consumers: [CONSUMERS]. Walk through the change field by field and give a verdict with the reason, as a table with Compatible or Breaking, Reason and Mitigation. Breaking examples: removing or renaming a field, changing a type, adding a required parameter, changing a status code or error format. Propose a safe path: add new fields, deprecate with notice, version, and migrate consumers. Tests to add before release: an old-client test sending the previous request format, a new-field test, and an error-format test. Provide a 90-day deprecation timeline with dates counted from a start date and messages at 90, 30 and 7 days, a rollback plan, and who may approve a breaking change. List ways to find consumers I may not know about: logs by client identifier, API keys, and asking teams. Mark tool details [VERIFY].
Fill in before use
Optional: type your details and the prompt above updates. Nothing is saved or sent.
Replace each bracketed placeholder with your own details, then paste into Any AI or another assistant.