Sync runs - Repo

A sync run is one execution of a connector’s sync logic — pull new items from the provider, normalize them, embed them, and store them.

List sync runs

GET https://api.userepo.com/v1/sync-runs

Requires sync:read. Returns recent runs for the organization, newest first.

{
  "syncRuns": [
    {
      "id": "uuid",
      "connectorId": "uuid",
      "status": "succeeded",
      "fullResync": false,
      "startedAt": "2026-05-30T20:00:00Z",
      "finishedAt": "2026-05-30T20:00:14Z",
      "itemsDiscovered": 18,
      "itemsIngested": 3,
      "errorMessage": null,
      "createdAt": "2026-05-30T19:59:55Z"
    }
  ]
}

string

queued → running → succeeded | failed.

integer

How many source items the provider returned for this run.

integer

How many were actually new (or updated) and stored. The difference is items filtered out (already seen, archived, etc.).

string | null

Surfaced from the underlying provider/connector error. Repo passes through provider error messages verbatim where possible.

Trigger a sync run

POST https://api.userepo.com/v1/sync-runs

Requires sync:write.

uuid

required

The source/connector to sync.

boolean

default:"false"

If true, discard the sync cursor and re-ingest every source item. Useful after a schema change or to backfill missing access policies. Slower and uses more provider API quota.

{
  "syncRun": {
    "id": "uuid",
    "connectorId": "uuid",
    "status": "queued",
    "fullResync": false,
    "createdAt": "2026-05-30T20:14:00Z"
  },
  "alreadyActive": false
}

If a sync run is already queued or running for this connector, the response returns the existing run with alreadyActive: true (HTTP 202). Repo enforces “at most one active run per connector” at the database level via a unique partial index — you can’t accidentally double-queue.

​List sync runs

​Trigger a sync run

List sync runs

Trigger a sync run