Practical checklist for validating large Zendesk JSON/NDJSON exports | The place for Zendesk users to come together and share
Skip to main content
August 3, 2026

Practical checklist for validating large Zendesk JSON/NDJSON exports

  • August 3, 2026
  • 0 replies
  • 36 views

Large full-account exports can look complete and still be difficult to validate. This is the checklist I use before treating an archive as reliable input for review or migration.

1. Identify the format of every file
NDJSON contains one JSON object per line, so parsing the whole file with JSON.parse will fail or consume unnecessary memory. ZIP exports may also contain multiple split files, so keep the source filename for every record.

2. Normalize a minimum ticket schema
Keep at least the ticket ID, created_at, updated_at, status, subject, requester/assignee/organization IDs, tags, custom_fields, and comment or audit data. Do not assume every export variant uses identical property names.

3. Validate the conversation history
Check public replies versus internal notes, comment order, author IDs, timestamps, and attachment metadata. A ticket record without its full conversation may be unusable even if the ticket count is correct.

4. Merge duplicate ticket records carefully
The same ticket can appear across split files or incremental pages. Merge by ticket ID, compare updated_at, and preserve all distinct comments rather than simply keeping the last object encountered.

5. Snapshot ticket field definitions
Store the ticket field metadata alongside the tickets. Multi-select values are option tags, not display labels, so you need the corresponding custom_field_options mapping to interpret them later.

6. Separate deleted or scrubbed tickets
Do not mix deleted placeholders with active tickets when calculating completeness. Track them as a separate category and record whether customer-provided content has already been scrubbed.

7. Record reconciliation counts
Useful checks include parsed records per file, unique ticket IDs, duplicate IDs, malformed lines, missing timestamps, missing conversations, and tickets with unknown custom field IDs.

8. Use privacy-safe test data
Start with a small anonymized sample. Real support exports can contain customer messages, internal notes, email addresses, and attachment names, so avoid uploading them to an unverified third-party service just to inspect the structure.

9. Perform deliberate spot checks
Manually inspect several open, solved, and deleted tickets, plus examples with internal notes, attachments, and multi-select fields. Automated counts alone will not catch every semantic mismatch.

Which export shapes have caused the most trouble for you: full JSON, NDJSON, incremental API results, or ZIP bundles? What do you verify before calling an archive migration-ready?