Review and approve campaign content

This guide shows the safe way to review generated campaign content for one prospect, edit individual messages, and then approve or discard the complete workflow run.

The approval model

One item returned by the approval API represents one prospect in one campaign workflow run. It is not a campaign-wide batch and it is not one standalone message.

Campaign
└── Prospect workflow run
    ├── Initial DM                 editable content
    ├── Wait 1 day                workflow timing
    └── Follow-up DM 1             editable content

The workflow run stays in waiting-approval while you review or edit it. A PATCH saves message changes without continuing the workflow. A later approval continues that same run; it does not create a second workflow run or a duplicate initial message.

Recommended endpoint sequence

Use API keys with campaigns:read for steps 1–2 and campaigns:write for steps 3–4.

1. List pending approvals

curl "https://api.sonarly.io/v1/accounts/$ACCOUNT_GROUP_ID/campaigns/content-approvals?page=1&limit=25" \
  -H "Authorization: Bearer $SONARLY_API_KEY" \
  -H "Accept: application/json"

Use campaignId when you only want approvals from one campaign:

curl "https://api.sonarly.io/v1/accounts/$ACCOUNT_GROUP_ID/campaigns/content-approvals?campaignId=$CAMPAIGN_ID&page=1&limit=100" \
  -H "Authorization: Bearer $SONARLY_API_KEY" \
  -H "Accept: application/json"

This endpoint uses one-based page pagination. limit accepts 1–100. Read currentPage, totalPages, and totalItems from the response; do not assume that the first 25 items are the complete result.

Unknown query parameters are rejected with 422 VALIDATION_ERROR. This includes misspellings such as limti=100.

2. Understand the workflow graph

Each approval contains two related views:

• workflowReview.nodes and workflowReview.edges describe the read-only workflow order and branches.
• Each pendingContent item has a nodeId and reviewContext that identify its position in that graph.

{
    "workflowInstanceId": "507f1f77bcf86cd799439071",
    "campaignId": "aabbccddee1122334455ca11",
    "leadId": "507f1f77bcf86cd799439072",
    "firstName": "Avery",
    "lastName": "Stone",
    "pendingContent": [
        {
            "nodeId": "aabbccddee1122334455ca21",
            "contentType": "direct_message",
            "message": 

Match content by nodeId, not by array position or label. Labels are for people; node IDs are the stable request keys for that approval payload.

3. Edit messages without approving

Send only the content items you want to change. This request saves the edits and leaves the run waiting for approval.

curl -X PATCH \
  "https://api.sonarly.io/v1/accounts/$ACCOUNT_GROUP_ID/campaigns/$CAMPAIGN_ID/workflow-runs/$WORKFLOW_INSTANCE_ID/messages" \
  -H "Authorization: Bearer $SONARLY_API_KEY" \
  -H "Content-Type: application/json" \
  -H "Accept: application/json" \
  -d '{
    "contentItems": [
      {
        "nodeId": "aabbccddee1122334455ca23",
        "message": "Would it be useful to compare how we keep approval workflows fast?"
      }
    ]
  }'

The editable field depends on the content type:

For multiline text, send normal JSON strings with \n line breaks.

Templates, variables, and Spintax

Use variables and Spintax in writing-style samples, where Sonarly can render them for each prospect before approval:

{Hi|Hello|Hey} {{ First_name }}, I noticed your work at {{ Company_name }}.

Supported profile variables are:

Signal-aware samples also support {{ Signal }} and {{ Signal_anonym }}.

Spintax uses one pair of braces and pipe-separated alternatives, for example {Hi|Hello}. Template variables use double braces. Sonarly resolves both before the content reaches the approval lane.

If you want deterministic wording, use a strict writing-style template and keep the alternatives and variables in that template. The approval endpoint is for reviewing or correcting the final prospect-specific result, not for storing a reusable template.

4. Approve or discard the complete run

If no message needs editing, skip the PATCH and approve the current saved content directly:

curl -X POST \
  "https://api.sonarly.io/v1/accounts/$ACCOUNT_GROUP_ID/campaigns/$CAMPAIGN_ID/workflow-runs/$WORKFLOW_INSTANCE_ID/approve" \
  -H "Authorization: Bearer $SONARLY_API_KEY" \
  -H "Content-Type: application/json" \
  -H "Accept: application/json" \
  -d '{}'

Approval applies to the complete pending content batch for this one prospect workflow run. It continues the existing run using its currently saved messages. Wait steps and branches still execute in their defined order; approval does not send every follow-up immediately.

To reject the complete run:

curl -X POST \
  "https://api.sonarly.io/v1/accounts/$ACCOUNT_GROUP_ID/campaigns/$CAMPAIGN_ID/workflow-runs/$WORKFLOW_INSTANCE_ID/discard" \
  -H "Authorization: Bearer $SONARLY_API_KEY" \
  -H "Accept: application/json"

Discard is terminal for that workflow run. It does not skip one content item and continue with the others.

Avoid duplicate or partial processing

• Treat workflowInstanceId as the approval unit.
• Re-read the approval before writing if another reviewer or process could act on it.
• Never use the one-off message response endpoint to replace a campaign-generated message.
• Do not create a new campaign run when an approval already exists; approve the existing run.
• After approval, use the activity log to distinguish planned follow-ups from actions that actually executed.
• Legacy /workflow-instances/.../approve requests with inline contentItems must include every pending item exactly once. Partial legacy batches are rejected without continuing the run.

Common errors

For exact schemas, open the Campaigns endpoint reference.