This endpoint lists every source one customer has connected, and what each one is doing right now. It is also how you discover connections you have no uid stored for. That happens after a connection_type.revoked, or when you are reconciling a partial signup.
GET /api/v1/api_accounts/:uid/connections/:connection_uid returns the same shape for one row. An unknown connection uid, or one belonging to another customer, is a 404.
Response fields
idintegeruidstringsite_url when you provision the account, so its uid is always site.connection_typestringnamestringstatusstringredirect_required, pending or connected.auth_statusstringpending_auth, authorised, auth_failed or disconnected.sync_statusstringunsynced, syncing, synced or error_syncing. A source that has not yet attempted a fetch is unsynced, never null.post_countintegerpost_request_limitintegerlast_synced_attimestampnull if it never has.The customer's memory connection is deliberately not listed. It holds what your product pushed, rather than a source the customer connected.
Reading the two statuses together
auth_status answers "can we still reach the source". sync_status answers "how did the last fetch go". They move independently, so a support screen should show both.
| Combination | What has happened |
|---|---|
pending_auth + null |
Waiting on the customer at the provider's consent screen. |
authorised + syncing |
Connected, first or subsequent fetch in flight. |
authorised + synced |
Healthy. |
authorised + error_syncing |
The source itself failed: an API outage, a removed folder. It retries on the next scheduled sync. |
auth_failed + anything |
The grant died. Content is kept; the customer must re-authorise. |
Polling is the fallback, not the plan. The connection.authorised and connection.auth_failed webhooks fire the moment either happens, and the per-organisation rate limit is shared across your entire fleet.