Connection status
Read one connection’s status with:
GET /v1/repositories/{repositoryId}/connections/{connectionId}/statusAuthorization and privacy
Section titled “Authorization and privacy”Send either a Sync-audience human OAuth bearer or a marketplace bot bearer.
The caller needs an unexpired sync:read decision for the route repository.
Route identifiers do not grant access. A 404 can mean that the connection is
missing or that it is not available through the repository in the request;
clients must not treat that response as proof that a connection exists.
An optional X-Request-Id must be a canonical ULID. When it is absent, Sync
generates one and returns the effective ID in both the response header and any
error body.
Response fields
Section titled “Response fields”The response contains:
- repository and connection IDs;
- backup or two-way mode;
- connection state and version;
- the last persisted update time;
- outage kind, reason code, observation times, and optional retry time; and
- conservative next-action guidance.
It does not expose provider or installation identifiers, credentials, or private recovery state.
Proven local scratch exhaustion uses the retryable
initial_import_runtime_capacity_exhausted reason. A GitHub or Gitdown capacity
response keeps its dependency attribution so callers do not mistake a remote
outage for local transfer capacity.
| Connection state | Guidance |
|---|---|
pending |
wait |
active |
none |
pausedPartial |
inspectRefs |
outage |
reviewOutage |
quarantined |
resolveQuarantine |
disconnecting |
wait |
disconnected |
none |
Guidance is descriptive, not authority. Import status, incidents, retry, resolution, safe resume, two-way enablement, reauthorization, and disconnect use separate resources with their own authorization and version checks.
See the bundled API reference for canonical schemas and error responses.