Repository navigation
Integrations: unlink and re-verify connected accounts #40
Description
Part of #38 — Social account linking (OAuth) and full cross-post destination support
DELETE /api/user/identities is already declared in the app's API layer; POST /api/user/identities/verify is not called at all.
Web behaviour (/help/cross-posting → Keeping your connections active): connections can go
stale and need re-verification, and the user can unlink an account.
- Add unlink (with confirmation — it stops cross-posting to that network) and re-verify actions
to the connected-accounts screen. - Show connection health (
connectedAt/lastVerifiedAtare already in the identities payload)
so a stale connection is visible before a post silently fails to syndicate.
Tests: unlink round-trip and list refresh; verify round-trip; stale state rendering.
Filed from the parity review of feature/parity-wip @ 14d7795 against interlinedlist.com (OpenAPI /api/openapi.json, 233 paths) and the public help centre.
Activity
Adron commentedon Sep 16, 2026
Implemented in the PR above (branch
issue/40-unlink-reverify). Closing here — review and any follow-up happens on the PR.Contracts settled:
DELETE /api/user/identitiestakesprovideras a query parameter (not a body or path segment), andPOST /api/user/identities/verifytakes{ "provider": … }as a JSON body. I also confirmed the identities envelope live —{"identities":[{id, provider, providerUsername, profileUrl, avatarUrl, connectedAt, lastVerifiedAt}]}— so the help page's bare-array example is wrong.One detail that shaped the design:
provideris instance-qualified. Your account really does havemastodon:techhub.social, so identities are rendered one row each rather than collapsed per platform — otherwise unlink would hit an arbitrary instance.Staleness threshold is 30 days, chosen as half of the shortest expiry the help centre documents (LinkedIn's "couple of months"). That gives about a month of warning before a cross-post could start failing silently.
One thing I deliberately did not verify: the response body of
POST /api/user/identities/verifyis ignored. If the server can answer 200 with something like{"verified": false\}instead of a 4xx, a failed verification would read as success until the refreshedlastVerifiedAtcontradicts it. Settling it means calling verify against your real linked accounts, which mutateslastVerifiedAt— say the word and I will.merge: #40 unlink/re-verify + connection health (PR)