Export, delete, and move your data

Data portability is a lifecycle question, not just an Export button. Decide what must leave GraphJSON, in which format, on what schedule, and what should happen to dashboards and queries after the source data changes.

This page documents the current self-service paths and their boundaries.

Choose the right export#

An iframe is not an export of the underlying rows. A CSV produced from a table is not proof that every raw event was included. Match the mechanism to the portability requirement.

Export Samples#

Use Samples to inspect event-level records:

1. open the collection
2. choose Samples
3. set the required time range
4. apply filters
5. review the visible columns and values
6. select the CSV export

CSV is convenient for inspection and small transfers. It has limitations:

• nested JSON may be flattened or represented differently from the original payload
• spreadsheet software can reinterpret timestamps, identifiers, and large numbers
• the result reflects the selected range, filters, ordering, and page
• CSV is not ideal for preserving arbitrary nested JSON exactly

After downloading, count the rows and inspect representative identifiers, nulls, nested values, timestamps, and non-ASCII text before treating the file as a migration artifact.

Export aggregated results#

Use a Table visualization or saved SQL query when the consumer needs a calculated result rather than raw events.

Examples:

• revenue by month and currency
• active accounts by plan
• webhook failures by provider
• API usage by customer

Record the query and definition next to the exported file. An aggregate without its filters, time zone, and exclusions cannot be reproduced later.

For programmatic retrieval, use the Data API. Build the result in the UI first and export the API payload so the request matches the reviewed chart.

Plan a large raw export#

GraphJSON does not currently publish a self-service endpoint that streams every raw event in a collection or workspace.

If complete raw portability is a requirement:

1. contact GraphJSON before launch or before a time-sensitive migration
2. identify the workspace and collections
3. define the time range
4. choose JSON Lines or another required representation
5. define how nested values and timestamps must be preserved
6. agree on a secure delivery method
7. verify counts and checksums after receipt

Do not wait until the final day of a contractual or regulatory deadline to discover that a chart export is not the required archive.

For systems that require a continuously available raw source of truth, keep the authoritative record in your own operational database, event bus, object storage, or warehouse and send GraphJSON an analytical copy.

Set retention#

Each collection can store events indefinitely or apply a retention period.

Use retention to match the useful and permitted lifetime of the data:

product_events: 400 days
webhook_diagnostics: 30 days
staging_events: 14 days
public_status_metrics: indefinite

Shortening retention affects data after it ages beyond the configured window. It is not a substitute for an immediate deletion workflow, and the visible stored-event count may not change at the exact moment the setting is saved.

Before shortening retention:

• export anything that must be preserved
• inventory dashboards, alerts, queries, and embeds that use older history
• identify annual or cohort analyses that would stop working
• record the policy owner and effective date

See Capacity, retention, and cost for storage planning.

Delete a collection#

Open the collection’s Settings, choose Delete Collection, and type the collection name to confirm.

Deletion clears the collection’s events and removes the collection resource. It is permanent from the customer workflow.

Before deleting:

1. stop producers and replay workers
2. preserve required data
3. list saved queries that reference the collection name
4. list dashboards, alerts, and embeds built from those queries or visualizations
5. notify owners of recurring reports
6. type the exact collection name and confirm
7. verify the collection is gone
8. remove unused integration mappings and secrets

Deleting event data does not automatically remove every dashboard, saved query, generated iframe URL, screenshot, CSV, or downstream copy that previously represented it. Clean up those resources separately.

Clear all events#

The virtual all_events collection includes a destructive Clear All Events action. It removes events across collections.

Treat this as a workspace-wide operation:

• stop all ingestion first
• confirm the exact workspace
• export required data
• notify every collection owner
• inventory dependencies
• type all_events only after completing the review

Do not use this action as a routine way to clean test data. Route test traffic to disposable collections with short retention instead.

Delete data for one person or account#

GraphJSON does not currently document a self-service row-level or user-deletion API.

If you need to remove records associated with one person or account:

1. stop new events for that identifier where required
2. identify every collection and identifier involved
3. identify exports and downstream systems that also contain the data
4. contact hi@graphjson.com with the workspace and affected collection names
5. do not include private values, API keys, or full event payloads in the initial email

If erasure by customer or subject will be a routine requirement, design collection boundaries and your authoritative data system before launch. A shared analytics collection is optimized for analysis, not as the only system responsible for privacy-request orchestration.

This documentation is engineering guidance, not legal advice. Your organization is responsible for defining applicable retention and deletion obligations.

Understand backups and recovery#

GraphJSON operates service backups for recovery from infrastructure failure. Those backups are not a customer-facing archive, version history, or guaranteed undo mechanism for an intentional collection deletion.

Do not rely on service backups to:

• restore one accidentally deleted dashboard
• reverse an intentional collection deletion
• retrieve an arbitrary historical snapshot
• satisfy your own archival or legal-retention requirement

Keep required source records in a system you control and test your own restore process.

Move to another system#

A migration is complete only when the destination reproduces the agreed facts.

Use this sequence:

1. define the cutover time
2. export a historical range
3. keep new events flowing to the old path during validation, or dual-write deliberately
4. transform timestamps and JSON without losing identifiers
5. compare counts by day and event
6. compare critical totals by currency or unit
7. sample end-to-end customer histories
8. move dashboards and consumers
9. stop ingestion to GraphJSON
10. wait through the agreed rollback window
11. delete data only after sign-off

Preserve stable event_id values so replays can be identified. Record whether the destination follows the original occurrence timestamp or the migration time.

Portability checklist#

• Authoritative source identified
• Required collections and time range listed
• Raw versus aggregate requirement decided
• Nested JSON representation tested
• Time zone and timestamp units verified
• Counts and critical totals reconciled
• Delivery method secured
• Downstream copies inventoried
• Retention and deletion owners recorded
• Dashboards, queries, alerts, and embeds cleaned up

Pair this page with Data lifecycle and privacy and Capacity, retention, and cost.