Complete a connection from a front-end that received the redirect

Redeem a code the front-end received at its own redirect URI.

The caller's workspace must be the workspace the state was minted for. That check is what stops an authenticated admin of one workspace from redeeming a consent screen somebody else was shown. The state is still the authority, and this route only adds a second, narrower gate on top of it.

The workspace goes into the claim, so a mismatch consumes nothing. Getting that backwards turns this route into a way to burn any state you can get hold of, and the victim's own redirect then fails as "invalid" with nothing to point at.

Tenancy: the request is scoped to one workspace, and the credential presented is what selects it. A caller with no membership in that workspace is refused with 404, which is indistinguishable from a workspace that does not exist.

Authorisation: admin or owner. An editor or viewer receives 403 insufficient_role.

Access: Authorization: Bearer carrying either a realm access token or an API key. A key must hold the channels:write scope, and the workspace role of the person who owns it must meet the floor above.

Response Body

curl -X POST "https://example.com/v1/channels/email/oauth/google/complete" \  -H "Content-Type: application/json" \  -d '{    "code": "string",    "state": "string"  }'

{  "connected": true,  "email_address": "string",  "scopes": [    "string"  ],  "sendable": true,  "polling": true,  "inbound_cursor_set": true,  "connected_at": "string",  "healthy_at": "string",  "last_polled_at": "string",  "sent_today": 0,  "checks": [    {      "check": "authorisation",      "status": "not_started",      "detail": "string",      "remediation": "string",      "last_checked_at": "2019-08-24T14:15:22Z"    }  ]}