Reject a draft — the lead skips the comment step and continues.
Authorization
bearerAuth An API key created under Settings → API & Webhooks.
In: header
Path Parameters
Response Body
application/json
application/json
application/json
application/json
curl -X POST "https://example.com/pending-comments/string/reject"{ "data": { "id": "string", "campaignId": "string", "campaignLeadId": "string", "leadId": "string", "stepId": "string", "status": "pending", "postUrl": "string", "postText": "string", "prompt": "string", "comment": "string", "firstName": "string", "lastName": "string", "headline": "string", "profileUrl": "string", "publicIdentifier": "string", "decidedAt": "2019-08-24T14:15:22Z", "postedAt": "2019-08-24T14:15:22Z", "createdAt": "2019-08-24T14:15:22Z", "updatedAt": "2019-08-24T14:15:22Z" }}Re-draft a comment POST
Ask the AI to re-draft the comment, optionally with a new instruction. Keeps the same post context.
Create a campaign POST
Creates a campaign (paused by default). You can set everything up front: the sender pool (`linkedinAccountIds`), the outreach `sequence` (its steps), the send `schedule`, `aiInterestEnabled`, the lead-exclusion rules (`excludeListIds` plus the `exclude*` flags), and the initial `status`. Anything omitted falls back to a sensible default (empty sequence, default 9-19 Mon-Fri schedule, paused). Then add leads with `POST /campaigns/{id}/leads` and set `status` to `active`. Sequence wiring: omit `id`/`parent`/`branch` on every step to have them auto-wired into a linear chain in array order (each step attaches to the previous step's natural continuation — the "yes" branch of a connection request or condition, but the "no"/still-no-reply branch after a message or InMail since their "yes"/Replied branch ends the sequence, otherwise its single child). To build a branching tree, give each step a stable `id` and set `parent`/`branch`. Once the lead is connected — the "yes" branch of a connection request (`invite`, "Accepted") or of an `if_connected` condition ("Connected") — the `invite`, `inmail`, `if_connected` and `if_open_profile` steps can't sit below it (the lead is already connected, so a connection request / InMail can't fire and a repeat connected / open-profile check is redundant). To send an InMail only when a request goes unanswered, wire it onto the invite's "no" (Still not accepted) branch, not the linear/"yes" continuation. The `inmail` step's `config.whenUnable` (`auto` | `pause` | `skip`, default `auto`) picks what happens when the InMail can't be sent (no premium InMail credits and the lead is not an open profile): `auto` pauses the sender when out of credits and otherwise continues to the still-no-reply branch, `pause` always pauses the sender, `skip` always continues.