Preview. The Migration API is in active design with a small group of
design partners. The surface below is what we’re building and how we’re
thinking about it — endpoints and payloads may change before general
availability. Want early access? Email vish@vern.so.
The shape of a source
A typical embedded migration is three steps:- Provision —
POST /api/v1/companiescreates a company for one customer. - Import —
POST /api/v1/companies/{id}/importspushes their files and runs your migration logic. It’s async; you poll for the result. - Deliver — download the validated data as CSV with
GET /api/v1/companies/{id}/export.csv, or push it to a destination system withPOST /api/v1/companies/{id}/exports.
Replay, not questions
Vern’s authoring experience is interactive and agentic — it asks clarifying questions, proposes mappings, and validates as it goes. That all happens once, in the UI, and produces a frozen, versioned artifact bound to your source. A normal import just replays that frozen logic headlessly, end to end, with no human in the loop — it never re-asks what you settled at authoring time. When a customer’s file drifts from the shape you authored against, it self-heals where it can and reports what it couldn’t. The only time questions come back is on your terms. If some rows still fail validation, you can take the valid rows and move on — or review: Vern surfaces the open questions and a proposed fix for you to render in your own UI, then re-runs once you decide. See Resolve flagged rows. See Core concepts for how sources, companies, and runs fit together.Next
- Core concepts — the model behind the API.
- Quickstart — provision, import, and download in one sitting.