Three formats
JSON. One object, keyed by table. The shape to use if you are moving into something you are building or scripting against.
CSV. One ZIP with one CSV per table. The shape to use if a person is going to open it, or a spreadsheet is.
SQL. One script of INSERT statements you can replay into your own PostgreSQL. The shape to use if you want a working copy of the database rather than a pile of files.
Getting it
From the dashboard, or from the REST API at GET /api/v1/data-export with format=json, csv or sql. No request, no queue, no waiting on us.
What is in it
Every tenant-scoped row that belongs to your organization. Members, tiers, categories, dues schedules, invoices and their line items, payments, events, registrations, communications, consent records, community content, and the rest.
The set is not maintained by hand and hoped for. A test in our own build fails if a model that holds personal data is not part of the export, so a new feature cannot ship with a table that quietly does not come with you.
What is not in it, and why
The audit log. Its integrity comes from a hash chain, where each entry is sealed against the one before it. Lifted out of that chain the rows are just text, and a copy of them would look like proof while proving nothing. Ask us and we will talk about what you actually need.
Stripe's own objects. Charges and customers live in Stripe, on your own Stripe account. The export includes the Stripe IDs so you can join against them, and you can pull the objects themselves from Stripe at any time. They were never ours to hold.
Getting rid of a member is a different thing
Exporting is taking a copy. Erasure is removing somebody, it is what a member is entitled to ask for, and it is not reversible. See privacy requests.
What we have not built
Scheduled exports. Delivery to your own S3-compatible storage on a nightly or weekly clock is on the roadmap and is not built. If you want it now, call the API endpoint above from your own cron. We will not describe it as shipped until it is.