Resume one stopped contact
Undoes a stop a person can take back. A reply stop (an auto-responder, or a bounce misclassified as a reply) and a mailbox_removed stop pick up exactly where they stopped; a cooldown stop starts at step 1. A mailbox_removed stop resumes only once the mailbox that emails the contact is back on the sequence. An unsubscribe or suppression stop is a compliance stop and is never resumable here.
Request
- Base URL: https://api.getoneprofile.ai (the document declares no server; this is the origin it was published from)
- URL: https://api.getoneprofile.ai/sequences/{sequence_id}/contacts/{enrolment_id}/resume/
- Auth: one of:
- API key in header X-API-Key
- HTTP bearer
Path parameters
Response
Successful Response
Their company, from whichever column of the audience row holds one.
The person's name from their audience row: a full-name column where filled, else the given and family names joined. Null when the table names nobody.
This contact's ordinal within the sequence, from 1. A label of last resort, for a contact with neither an address nor a LinkedIn profile.
Their job title, from whichever column of the audience row holds one.
For a contact on a condition that waits (Replied?, Bounced?, Accepted?), or waiting for a connection request's answer: when the branch is decided. On a request it is when its answer window closes; in the past, the window is over and one more reading decides.
Which kind of failure stopped a FAILED contact, where the product treats one differently.
Stored beside failure_reason and cleared with it. Most failures carry no code: Retry runs the step that broke again. CONNECTED_BEFORE_WITHDRAW is a Withdraw that found the person already connected: there is nothing to withdraw and nothing to retry, so no Retry offers it. INVITE_LOOK_UNREADABLE is the profile look a connection request queued to learn its answer, which could not read the relationship: Retry queues a fresh look rather than sending the request again.
Why a failed contact stopped, in the words of its status cell: for a LinkedIn step, the browser's own reason. Retry runs the same step again. Null on every other status.
Why the send path pushed a live contact's due_at out instead of sending.
Stored beside the date it explains so the Contacts tab can say "Approved, window opens in 3 hours" rather than a bare date. Only ever meaningful on an ACTIVE row whose date is still ahead; any other write clears it.
When the connection request this contact stands on went out, or was first seen already pending: set while they wait for its answer (and kept through a pause or a stop). Null on every other step, and on a completed contact.
The touch a cooldown stop is measured from. Whoever made it is deliberately never named, because it may be a colleague's sequence entirely.
When that step ran.
The step this contact last actually ran. Not the step before current_step_id: on a branching graph those are different steps.
Where one step stands in its account's line, for the people waiting on it.
RUNNING is in a browser now. QUEUED is in line, with how many are ahead of it and when it is expected to start. The rest say why the line is not moving for it: a daily or weekly limit reached for its kind, a limit set to zero (KIND_DISABLED, which no reset lifts), no browser checked in for longer than offline_warning_seconds, LinkedIn asking the member to verify the account (a checkpoint), or the account disconnected. Not "paused", which is already what a sequence is when a person stops it.
The last two were one "account blocked" state. They are two because the fix is different and the words have to say which: a checkpoint is cleared in the connected Chrome, a disconnect by connecting again.
OUTSIDE_WINDOW is a step whose sequence's sending hours are shut now in its sender's timezone (2026-10-01); it outranks every state but the account's own, since nothing else moves it before the hours open.
CHECKING_REPLIES is a LinkedIn message in line that waits for its sender's inbox to be read first (2026-10-05): no time is named, since it goes once a check reads the whole inbox.
For a step held by a daily or weekly limit, when the limit it waits on resets (midnight in the sender's timezone). Null otherwise.
When the step is expected to start, simulated the way the account's governor hands steps out: the next gap is exact, later gaps are the account's time between steps widened by the average jitter, and a step held by a daily or weekly limit starts after that limit resets. Null where no time can be named.
For a queued step, how many of the account's steps run before it.
The address this contact is emailed from. A contact is only ever emailed from the mailbox that first emailed them, in any sequence. Null until something has emailed them.
Why the mailbox a contact is emailed from cannot send for them right now.
Read at the time, never stored. The first two stop the contact, because nothing on its own brings the address back to this sequence; the last two make them wait, because a reconnect or a sender does.
Whether any channel this sequence's steps use can reach the contact: an email address for an email step, a LinkedIn profile URL for a LinkedIn one. A sequence with no sending step yet counts both.
Where one contact stands in one sequence.
ACTIVE rows carry a due_at and are what the tick claims; CLAIMED is the in-flight guard between claim and outcome. PAUSED is a deliberate per-contact hold: unclaimable because the tick claims strictly on ACTIVE, yet still LIVE. It keeps its step and its one-live-sequence slot, and a compliance stop (reply, unsubscribe) reaches it. Everything else is settled: COMPLETED walked off the end; STOPPED was halted (reply, unsubscribe, bounce, manual, company pause); FAILED is terminal; SUPPRESSED was on the do-not-contact list; SKIPPED_DUPLICATE lost the one-live-sequence-per-contact rule, with the reason visible in the grid.
A contact the workspace's recontact rule refuses is STOPPED with StopReason.COOLDOWN. There is deliberately no held state: a cooldown settles a contact rather than parking them, so nothing here waits on a date and nothing lets itself out later.
AWAITING_ACTION is a contact parked behind a task that needs a person or a channel, modelled on PAUSED: live, keeps its step and its one-live-sequence slot, unclaimable because the tick claims strictly on ACTIVE, and a compliance stop reaches it. Unlike PAUSED nobody wakes it by hand: only the outreach-task sweep does, once the task it waits on is decided or delivered. Deliberately not "awaiting approval": an AUTO-mode LinkedIn park is waiting for a browser rather than for anyone's approval, and this value is the word the Contacts tab shows for both.
PENDING is a draft's roster: in, standing on a step, and NOT live. Binding an audience enrols on the spot so the Contacts tab can show who is in, but a sequence nobody has launched must not hold anybody's one-live-sequence slot, or a second sequence written for the same people skips them all. uq_sequence_enrolment_one_live leaves PENDING out, the tick never claims it, and launch turns each row ACTIVE, settling the ones another sequence took meanwhile as SKIPPED_DUPLICATE.
Which address a contact lacks for the channels their sequence uses.
Derived at read time from the contact's row and the graph, never stored. Named by channel rather than as one "missing contact details", because the fix is different: an email-only cadence needs an address, a LinkedIn-only one a profile URL.
What a live contact is held behind in the approval queue, read at list time.
Derived from the contact's task for its current step, never stored: the task is the truth, and a copy on the enrolment would lag behind it.
Changes
No recorded changes to this operation across all 1 revision of this API.