Export your data

Export any table on your board to CSV. Use it to back up your data, analyze it in a spreadsheet, move a subset into another tool, or hand a clean file to a teammate. Export is the inverse of Import: where import brings jobs, companies, and blog posts in, export takes any of your primary tables out.

Where export lives

Every primary table has a ... menu in its toolbar, next to the primary action (for example, next to Import on Jobs, or next to Add on Companies). Open that menu and choose Export. The same step works everywhere, so you do not have to learn a different control per page.

1. Open the table you want to export (Jobs, Companies, Employers, Candidates, Job alerts, or a blog table).
2. Click the ... menu in the toolbar.
3. Choose Export.
4. Your browser downloads a CSV named for the entity and your board.

What you can export

Eight tables are exportable:

Every file is comprehensive. Alongside the fields you authored, each row carries its id, its status, and its created and updated timestamps, so an export is a complete snapshot of the table.

Exports that re-import cleanly

Jobs, companies, and blog post exports use the same field vocabulary as the matching CSV import. That means a file you export round-trips: you can re-import it (into the same board or a new one) without remapping columns. See Import jobs from CSV or XML and Company and subscriber import for the field details.

Large exports

Typical boards produce the CSV immediately and the browser download starts at once. When a table has more than 10,000 rows, the export switches to a Preparing export... state and prepares the file in the background. You can leave the page while it runs. When it finishes, the action gives you a download link for the completed file.

Large exports are capped at 200,000 rows. If a table is larger than the cap, export the rows you need by filtering the table first, or reach out and the team can help with a full extract.

Permissions

Exporting a table requires that entity's read permission (for example, jobs.read for the jobs export, candidates.read for the candidates export). Account owners and admins have these permissions by default, so on most boards export just works. Members on a restricted role only see the Export action for tables they can already read.

Exports above 10,000 rows prepare in the background and additionally require the operations.read permission to prepare and download the file. Account owners and admins hold it by default; a restricted role needs it added before a large export can run.

Resume links in the candidates export

The candidates export includes each candidate's resume as an authenticated download link, never a public file URL. Opening a link requires a signed-in operator with candidate read permission, so a resume cannot be reached by anyone who happens to hold the CSV. Treat the exported file itself as sensitive: it contains candidate contact details and links to their documents.

Export over the API

Every dashboard export has a matching v1 API endpoint:

1234567
GET /api/v1/jobs/export
GET /api/v1/companies/export
GET /api/v1/employers/export
GET /api/v1/candidates/export
GET /api/v1/blog/posts/export
GET /api/v1/blog/authors/export
GET /api/v1/blog/tags/export

Each endpoint takes a format parameter:

• format=json returns the rows inline in the response, for up to 10,000 rows. Use it for scripts and small tables that you want to process directly.
• format=csv starts an async operation and returns an operation record. Poll the operation, then download the finished CSV from GET /api/v1/operations/{id}/download once it succeeds. Use it for large tables and for a file you want to store.

This is the same pattern as the existing subscribers export endpoint (GET /api/v1/subscribers/export). See the API reference for authentication, pagination, and the full parameter list.

Applications are not exportable

Applications do not have an operator export, by design. An application belongs to the employer's hiring pipeline, not to the board operator. Operators own the board's content (jobs, companies, and the surrounding data), while the employer who receives an application owns that application and moves it through their own pipeline. This is a deliberate ownership boundary, not a missing feature. Operators can still manage job listings, companies, candidates, and subscribers with the exports above.

Next steps

To bring data back in, see Import and export for the import flows. To move an existing board onto Cavuno, export from your current tool, then follow Import jobs from CSV or XML and Company and subscriber import.