How to use the API Response Diff Tool.
Separate structural changes from value changes. A changed example value does not necessarily break an API contract, while a removed field may matter.
Make the workflow fit your task.
Compare response structures and values separately, preserving paths to each change. Distinguish removed or renamed fields from example-value changes, then assess compatibility against the consumers' actual requirements.
- What you provide
- Two sample responses and comparison rules.
- What you get
- Schema and value changes with compatibility concerns.
See the input and the result.
Illustrative input and output · a teaching example, not a live WebAct run
Example input
Compare response field sets. Old: {"id":"A1","name":"Ada"}. New: {"id":"A1","display_name":"Ada"}. No API compatibility contract supplied.Completed example
Unchanged field: id. Removed field: name. Added field: display_name. Potential impact: clients reading name may fail or lose displayed text. A rename is plausible, but the samples alone do not prove semantic equivalence or the full compatibility policy.
Load this input into the prompt, then copy it to WebAct to try the task. Your result may differ from the illustration.
Decisions and troubleshooting.
Does a changed example value automatically break an API contract?
No. A value may legitimately vary. Schema, meaning and consumer assumptions determine whether the change is significant.
Why does a renamed field appear as unrelated removal and addition?
A structural diff cannot prove intent. Mark the possible rename and confirm it against the documented change and consumer usage.
Try it with your own source.
Replace the example with your material in the task prompt. Keep the requirements you need, then copy the task into WebAct.
Customize and copy the task ↑