Guide
How to Prepare Logs and JSON Payloads for Vendor Support
A field-tested workflow for turning logs, timestamps, encoded values, and JSON payloads into useful support examples.
Last updated: 2026-07-23
Define the failure before collecting data
A support ticket is easier to solve when the failure is stated in one sentence: an export failed, a webhook returned the wrong status, a queue job ran late, or a customer record did not sync. Collect only the logs and payloads needed to support that statement.
Format JSON before editing it
Compact payloads hide useful structure. Format the JSON first, then identify the objects and fields relevant to the bug. Once the shape is visible, it is easier to remove unrelated sections without breaking the example.
Redact without changing data types
Replace tokens, emails, customer IDs, session values, account numbers, and private URLs with placeholders. Preserve data types: strings should remain strings, booleans should remain booleans, numbers should remain numbers, and arrays should remain arrays. Type changes can hide the real integration issue.
Decode only the relevant encoded value
Logs may include URL-encoded parameters, Base64 values, hashes, or opaque tokens. Decode the part that helps explain the problem, not every value in the log. Remember that URL encoding and Base64 are reversible formats, not security protections.
Normalize timestamps to UTC
A vendor may read a ticket in a different timezone than your team. Convert event times to UTC for the technical timeline, then include local time only as supporting context. Keep original values beside converted values so the vendor can reproduce the sequence.
Keep samples small but complete
A good support example usually includes one failing request, one relevant response, the error message, the request ID, and a short timeline. Sending a full production log dump can slow review and expose more data than necessary.
Check syntax after redaction
JSON, URLs, and copied log lines can break during cleanup. Validate the final payload and re-read the formatted version before sending it. A support team should not have to fix accidental commas or missing quotes before investigating the actual issue.
Write the review note
Add a plain-language note explaining what changed: which fields were redacted, which timestamps were converted, and which system produced each line. This note helps the receiving team trust the sample without needing the full private dataset.