Why raw responses are risky
API responses often include more than the one field you care about. They may contain customer names, emails, IDs, internal notes, IP addresses, auth-related metadata, and billing information all in the same body.
What to keep and what to remove
Keep the structure, status fields, and non-sensitive operational values. Remove the data that identifies a real person, exposes a credential, or reveals information that is not necessary for the debugging point you are making.
Good sanitized examples are still useful
A good debug example does not need to be raw. It only needs to preserve the relevant schema, nesting, and type information so another engineer can understand the issue.
Suggested workflow
- Paste the response into the masker.
- Run default masking.
- Add any product-specific custom fields.
- Verify that the response still explains the issue clearly.