Example
Prepare a JSON Bug Report Without Exposing Secrets
A JSON workflow for formatting a payload, preserving data types, and redacting fields before sending a support ticket.
The situation
A support engineer needs to send a failing API response to a vendor. The payload includes useful error context but also contains a bearer token and a customer email address.
Original compact payload
{"ok":false,"request_id":"req_91a","customer":{"email":"[email protected]","plan":"pro"},"auth":"Bearer secret-token","error":{"code":"timezone_mismatch","timestamp":1784371200000}}Workflow
- Format the payload so the customer object, auth field, and error object are easy to see.
- Replace the email and bearer token with placeholders while keeping both fields as strings.
- Keep request_id if the vendor needs it for log lookup, or redact it if policy requires.
- Convert the millisecond timestamp separately and add the UTC value in the ticket notes.
- Validate the final JSON after redaction.
Redacted JSON example
{
"ok": false,
"request_id": "req_91a",
"customer": {
"email": "[redacted-email]",
"plan": "pro"
},
"auth": "[redacted-token]",
"error": {
"code": "timezone_mismatch",
"timestamp": 1784371200000
}
}Review checks
- The final JSON remains syntactically valid after redaction.
- String values are still strings, numeric timestamps are still numbers, and booleans are unchanged.
- The support ticket includes enough context to reproduce the error without exposing credentials.