Connections
A venue’s own vendor accounts, as the ledger actually holds them. Every control on this page calls a real endpoint and nothing here is drawn from a hard-coded list — the rows, the states, the outcomes and the failure messages all come from GET /v1/ops/connections. Where the API returned nothing, this page says what is absent and why, because an empty cell reads like a finding and a null is not one. Linked is not the same as working, and the two are never merged into one dot.
Link this venue’s Klaviyo account
The key is verified against Klaviyo before anything is stored. A key Klaviyo refuses is not filed at all — you get the refusal, not a row that exists only to expire. A key that authenticates but cannot be confirmed (Klaviyo unreachable, or the key cannot read /accounts) is filed, and lands in the ledger below saying exactly that.
400 carrying
Klaviyo’s own reason, and nothing is stored.
ops:connectors:writeWhat is on file, and what we last learned
Each row carries two clocks and two chips. STATE is the ledger’s own state machine. HEALTH is what the last check learned — or that there has never been one. They are different facts and a row that merges them cannot tell you that a credential worked yesterday and was refused a minute ago.
Reading GET /v1/ops/connections…
ops:connectors:readPOST /v1/ops/connections/:connectionId/check · POST /v1/ops/connections/:connectionId/revoke · scope
ops:connectors:write
Six readings, because they call for six different actions
Collapsing these into working / broken is what makes an operator re-paste a key that was never the problem. Amber is the heaviest weight on this page; nothing here is ever red.
state: linked with lastCheckOutcome: null. A credential is on file and nobody has ever asked the provider whether it works. Not healthy, not broken. Press CHECK NOW to turn it into a fact.ok. The provider answered as this credential’s owner. The claim is pinned to a timestamp because it is a claim about a moment, not a property of the row.auth_rejected. Positive evidence the credential is dead — revoked or rotated at the provider. This is the only outcome that means paste a new key. The heaviest weight on the page.insufficient_scope. The key authenticated; it simply is not allowed to read what we asked for. Widen it at the provider, then press CHECK NOW — the credential stays on file and does not need re-pasting. This is not an expiry.provider_unreachable. A statement about the provider, not about the venue’s key. We learned nothing either way. Nothing to fix here; check again later.misconfigured. ATLAS could not use the stored credential — typically a keyring this deployment does not hold. Not the venue’s fault and not counted against their key. Raise it with the platform.