Skip to main content
POST
Queue one LinkedIn step by hand

Authorizations

X-API-Key
string
header
required

Path Parameters

profile_id
string<uuid>
required

Body

application/json

Queue one step by hand, to watch the channel work.

The kind is a two-member literal rather than the full action enum: these are the ones the extension implements and that act on a single named profile. An InMail spends the sender's own premium credits and the housekeeping reads act on nobody, so neither is a useful thing to try on demand.

kind
enum<string>
required

What to do: view the profile, or send a connection request.

Available options:
profile_view,
connection_request
profile_url
string
required

Whose profile, in any shape LinkedIn uses — a vanity URL, a bare slug, a Sales Navigator link.

Required string length: 1 - 512
note
string
default:""

The invitation note, for a connection request. Ignored for a profile view.

Maximum string length: 300

Response

Successful Response

account_id
string<uuid>
required
claimed_at
string<date-time> | null
required
duration_ms
integer | null
required
error_code
enum<string> | null
required

Why one action did not succeed, as a closed vocabulary.

Two populations in one enum, on purpose. The first twelve are reported by the browser agent and were previously a free string that only the extension had written down — nothing stopped a typo storing and rendering exactly like a real code. The last three the backend writes itself when an action settles without the browser ever running it.

The list is the whole contract: a code outside it is rejected at the API boundary rather than persisted, so the extension and the dashboard can only ever speak about failures both sides can name.

Available options:
selector_missing,
blocked_checkpoint,
not_authenticated,
account_mismatch,
navigation_failed,
timed_out,
linkedin_error,
agent_restarted,
tab_lost,
not_applicable,
not_connected,
invalid_params,
user_rejected,
cancelled,
missed_window
error_message
string | null
required
expires_at
string<date-time> | null
required
finished_at
string<date-time> | null
required
id
string<uuid>
required
kind
enum<string>
required

What the browser agent is being asked to do.

The three CHECK_*/READ_* kinds are housekeeping — they read our own outbound invitations and our own conversations to detect what the contact did — so they are free and deliberately excluded from the priced kinds below.

CHECK_INBOX scans the conversation list for threads with new inbound activity; READ_CONVERSATION opens one of them and reads it in full. The split keeps LinkedIn activity proportional to real replies: the cheap scan runs on every sweep, the expensive read only where the scan saw a change.

LIKE_LATEST_POST targets the contact's most recent post at the moment the browser runs it. A contact with no posts is not a failure: the driver reports the action SKIPPED, and the sequence advances either way.

A PROFILE_VIEW outcome MAY additionally carry open_profile: bool — whether the member's Premium "Open Profile" toggle is on, read off the page when the driver can see it. The open-profile condition resolves from that observation and never from a guess, so a driver that cannot tell simply omits the key.

Available options:
profile_view,
connection_request,
send_message,
inmail,
withdraw_connection_request,
follow_contact,
like_latest_post,
check_sent_invitations,
check_inbox,
read_conversation
outcome
ProfileViewOutcome · object
required

What a profile view saw.

open_profile is deliberately three-state. The Premium "Open Profile" toggle is only sometimes legible on the page, and the sequence condition resolves from a real observation or not at all — None means "could not tell", which is not the same answer as False.

params
ProfileViewParams · object
required

Open a member's profile and read it like a person would.

priority
integer
required
queued_at
string<date-time>
required
source_enrolment_id
string<uuid> | null
required
source_step_id
string<uuid> | null
required
status
enum<string>
required

Where one queued action stands.

Governor-deferral is deliberately NOT a status: an action whose kind has hit its daily cap stays QUEUED and is simply not handed out, with the reason travelling on the hand-out response instead. A DEFERRED row would make the queue lie about what is still waiting to happen.

SKIPPED is "not applicable" (no LinkedIn URL, already connected); REJECTED is "a human refused it"; FAILED is "we tried and could not".

Available options:
queued,
claimed,
succeeded,
failed,
rejected,
skipped
approved_at
string<date-time> | null
approved_by
enum<string> | null

Which surface approved a manual step; the two are peers, never a hierarchy.

Available options:
web,
extension