Data source detail
The per-source view: connection status, last-sync metadata, error log, and the manual sync / pause / config controls a data operator needs.
Data source detail
Open any source at Data → Sources → to see its live connection
state and the controls an operator needs. The page reads
GET /v1/data/sources/{id} and mutates through the same source endpoints —
there is no separate detail API.
What the page shows
- Status badge —
idle,syncing,error, ordisabled, straight off the row (erroris set when a sync fails). - Last sync snapshot —
last_synced_at,last_records_count, andlast_error(the error block only renders when the last sync failed). - Connection config — the editable
config_jsonfor the source'skind.
Single snapshot, not a run timeline yet
The backend currently persists only the most recent sync outcome on the
source row (last_synced_at + last_records_count + last_error). There is no
sync_runs history table today, so the detail page shows a single snapshot
rather than a run-by-run timeline. When a real run-history table lands, the
timeline section can adopt it without an API change.
Controls
- 1
Manual sync
POST /v1/data/sources/{id}/syncstarts a sync. Whilestatus = syncingthe page pollsGET /v1/data/sources/{id}every 3 seconds so the UI never sits on a stale "syncing" state. As noted on the Data sources page, the sync body itself is an inline simulation today. - 2
Pause / resume
PATCH /v1/data/sources/{id}with{"status":"disabled"}pauses the source;{"status":"idle"}resumes it. A disabled source rejects sync requests. - 3
Edit connection config
PATCH /v1/data/sources/{id}with aconfigobject rewritesconfig_jsonin place — credentials and per-provider settings never change the row shape.
# Kick a manual sync and poll for the result
curl -X POST https://api.pact.place/v1/data/sources/42/sync \
-H "Authorization: Bearer $PACT_API_KEY"
curl https://api.pact.place/v1/data/sources/42 \
-H "Authorization: Bearer $PACT_API_KEY"
# → { "status": "idle", "last_records_count": 1284, "last_synced_at": "…" }
Cross-tenant lookups return 404, never 403 — every query is scoped to your
tenant, so an id that belongs to another tenant simply isn't found. (The {id}
path param is the internal integer id today; the routes type it as int, so a
UUID public_id is not yet accepted on this surface.)