Approvals
POST
/pending-comments/{id}/reject

Reject a draft — the lead skips the comment step and continues.

Authorization

bearerAuth
AuthorizationBearer <token>

An API key created under Settings → API & Webhooks.

In: header

Path Parameters

id*string

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.