Skip to main content
Returns the settled record of a migration: the plan, the files that went in, who approved what and when, how many rows were written per sheet, and whether existing rows were replaced. It’s designed to be fetched once, after the migration finishes, and stored on your side — so months later you can answer your own customer’s “what did you do to my data?”. This is not the live feed. For a run in progress use Stream the thread; the log deliberately excludes the conversation and returns the outcome instead.
Available only once the migration has settled. While anything is still in flight the endpoint returns 409 rather than a partial log — see Availability.

Authentication

Requires an x-api-key header. See Authentication.

Query

string
default:"json"
json (default) for the structured log, or md / markdown for a human-readable transcript you can paste into a ticket or hand to a customer.

Availability

The log covers every run to date, so it’s a superset of anything you fetched earlier — a migration re-imported later returns a longer log. It’s gated on the migration being settled, which deliberately includes failures: a run can write rows and then fail validation, and that’s exactly when someone asks what happened. completed, failed and canceled all return a log. While a run is still going you get 409 with the current status, so a poller can tell “not yet” from “broken”:

Response

200 OK.

Fields

string
When this log was produced. The log always covers everything up to this moment.
string
The migration’s settled state — completed, failed or canceled.
object
How much this log spans — { runs, from, to }, the number of runs and the timestamp range they fall in.
object[]
Every run, oldest first.

Markdown

?format=md renders the same data as a readable transcript — run headings, the plan, an audit table, and the result. Labels mirror the History tab in the Vern dashboard, so an export you hand a customer and what your team sees in-app tell the same story.

Errors

What the log cannot tell you

Worth knowing before you build a compliance story on it:
  • No per-row lineage. The log says a run wrote 48,213 rows to Contacts. It cannot say output row 4,312 came from line 4,180 of contacts.csv.
  • “Failed” doesn’t mean “untouched”. A run can insert rows and then fail validation. Read outcome.rows_written, not just status.
  • It isn’t tamper-evident. The underlying run records are mutable by users in your account. Treat the log as a faithful report, not as an audit seal.
  • Retention is keyed to the workbook. Logs are swept with the migration’s data under your retention policy. This is the argument for fetching and storing the log yourself.

Example

Next