GET /api/v1/connect/linkedin

Not supported: LinkedIn session connect has no OAuth link. POST the session cookies instead

GET
/api/v1/connect/linkedin

Authorization

BearerAuth
headerAuthorizationBearer <token>

API key sk_...

Response Body

Use POST

application/json
  1. response
error*
Example Request
curl -X GET 'https://example.com/api/v1/connect/linkedin'
Example Response405
{  "error": {    "message": "string",    "code": "confirmation_required"  }}

POST /api/v1/connect/{platform} POST

OAuth authorization URL for the account owner (valid 10 minutes, single use). Facebook: the owner picks Pages; the result may be a pending connection. WhatsApp: a Postgale page that runs Meta's Embedded Signup (several numbers → pending connection). Telegram has no OAuth: the answer is a one-time code (15 minutes) and instructions: a chat admin adds Postgale's bot as an admin with the right to post and sends /connect <code> in the channel or group (or forwards that channel post to the bot); the chat then appears in GET /api/v1/accounts and account.connected is emitted. Discord: a server admin installs Postgale's bot (scope bot) and picks channels, one account per channel (platformAccountId = channel id); POST /api/v1/connect/discord binds more channels of that server (without DISCORD_BOT_TOKEN the link creates a channel webhook instead, platformAccountId = webhook id). Mastodon needs instance (the server's domain; public DNS names only): Postgale registers itself on that server if needed and the link opens its authorization page (platformAccountId = <id>@<server>). Bluesky has no OAuth: POST {handle, appPassword} (a Bluesky app password, never the account password) connects the account right away and answers {platform, account}; a refused handle or password is a 400. Platforms that are not live on this instance answer 400. Same as GET with externalId (and instance) in the JSON body; Bluesky needs POST with handle and appPassword

POST /api/v1/connect/linkedin POST

Connect (or with accountId reconnect) a LinkedIn account with the member's own web session: cookies (li_at and JSESSIONID at least) and the user agent of the browser they came from. No OAuth, no password. country (ISO-3166 alpha-2, required) and city (optional) choose where the server-side residential proxy the session goes through exits; any proxy sent by the caller is ignored. The jar is validated, sealed (encrypted) and stored; responses never contain cookie values. While approval applies to the key, the organization or the account, the connect is queued (202, kind account.linkedin_connect, the queued call carries the jar already sealed). Availability: PROVIDER_LIVE_LINKEDIN_SESSION (or mock outside production)