Start a LinkedIn connect for a sender profile
Connect a LinkedIn account to this sender profile: the browser is remembered for 24 hours, so the account it produces binds here instead of birthing a sender profile. One browser source per call (two is 422). proxy_country_code or custom_proxy_config answers a cloud-browser login link a human signs in to (result.mode connect); public_link makes it a two-day link for whoever holds the password, mailed to public_link_email when given (result.sent_to_email). vendor_profile_id answers no link: its browser is found or created and run, the profile's signed-in session births the account (result.mode run: follow get_sender_profile_linkedin_connect_status until bound or failed), or the account gtm-api already holds on it binds at once (result.mode bound). A sender profile that already holds an account gets the re-login link of that account's browser (result.mode relogin; 409 linkedin_browser_missing: detach and connect again). A repeat while a browser is pending reuses it (a new link, never a second browser); on 503 linkedin_connect_unconfirmed call again in a minute, the browser gtm-api made is picked up.
Refusals: 422 proxy_pool_empty, vendor_profile_not_found, vendor_profile_no_run_access; 409 linkedin_profile_held_elsewhere, linkedin_profile_busy, linkedin_browser_no_server; 402 linkedin_sender_profiles_full (the plan's LinkedIn sender profiles are all in use) or subscription_required; 403 gtm_scope_missing; 501 while the gtm bridge is unconfigured.
Contract:
- MCP tool start_sender_profile_linkedin_connect, registry package mcp.unibox/sender_profiles, mount unibox.sender-profiles.
- Operation action, response envelope action.
- Flags: none.
Request
- Base URLhttps://beta.getsales.io/unibox/v1
- AuthHTTP bearer and API key in header Team-SID
Path parameters
Sender profile sid (ub_sp_…).
Request body
Response
action success envelope.
Changes
No recorded changes to this operation across all 1 revision of this API.