Inspect scheduled and executed activity

The account activity log answers two different questions in one response:

1. What is currently planned for this account?
2. What actually executed, succeeded, or failed?

Use it when the dashboard shows little activity, when a customer reports missing messages, likes, or comments, or before approving repaired content that might otherwise duplicate an existing action.

Request the default window

The default request returns a bounded operational window covering seven days before and seven days after the request time.

curl "https://api.sonarly.io/v1/accounts/$ACCOUNT_GROUP_ID/activity" \
  -H "Authorization: Bearer $SONARLY_API_KEY" \
  -H "Accept: application/json"

The API key needs activity:read and access to the requested account group.

Choose a precise window

For repeatable audits, pass explicit ISO 8601 timestamps in UTC:

curl "https://api.sonarly.io/v1/accounts/$ACCOUNT_GROUP_ID/activity?from=2026-07-07T00:00:00.000Z&to=2026-07-14T23:59:59.000Z&limit=100" \
  -H "Authorization: Bearer $SONARLY_API_KEY" \
  -H "Accept: application/json"

from must be earlier than to, and the requested window cannot exceed 14 days. Use several non-overlapping requests for a longer audit.

Unknown query parameters are rejected with 422 VALIDATION_ERROR; misspelled filters are never silently ignored.

Filter the result

Supported action types are invitation, direct_message, inmail, email, like, comment, profile_view, invitation_withdrawal, wait, condition, and sync.

For example, inspect failed direct messages from one campaign:

curl "https://api.sonarly.io/v1/accounts/$ACCOUNT_GROUP_ID/activity?campaignId=$CAMPAIGN_ID&type=direct_message&state=failed&from=2026-07-07T00:00:00.000Z&to=2026-07-14T23:59:59.000Z" \
  -H "Authorization: Bearer $SONARLY_API_KEY" \
  -H "Accept: application/json"

Read an activity item

{
    "id": "activity_01K0Q8H8T2A6B4C9D3E7F5G1J0",
    "displayAt": "2026-07-14T11:47:37.000Z",
    "scheduledAt": "2026-07-14T11:45:00.000Z",
    "executedAt": "2026-07-14T11:47:37.000Z",
    "originalScheduledAt": "2026-07-14T11:45:00.000Z",
    "nextScheduledAt": null,
    "type": "direct_message",
    "state": "sent",
    "deliveryState": 

The timestamp fields have different meanings:

workflowStepLabel gives the human-readable workflow position, such as Initial DM, Wait 1 day, or Follow-up DM 1. Use workflowInstanceId, leadId, and nodeId when correlating the log with campaign approvals.

Interpret state and delivery

The top-level state describes the normalized activity lifecycle:

For delivery actions, deliveryState narrows the outbound status to queued, scheduled, processing, sent, failed, deferred, or rejected.

Use these checks in customer-facing reports:

• provisional: true means the entry is a current plan, not proof of delivery.
• executedAt plus state: sent or state: succeeded is evidence that Sonarly executed the action successfully.
• state: failed or state: rejected means no successful delivery is recorded for that activity item.
• A sent DM is not proof that the recipient read it or replied. Read and reply state come from messaging and workflow status surfaces.
• content is the rendered content associated with the activity. Do not treat it as a reusable template.

Continue pagination

Results are cursor-paginated. When hasMore is true, pass nextCursor unchanged:

curl "https://api.sonarly.io/v1/accounts/$ACCOUNT_GROUP_ID/activity?from=2026-07-07T00:00:00.000Z&to=2026-07-14T23:59:59.000Z&limit=100&cursor=$NEXT_CURSOR" \
  -H "Authorization: Bearer $SONARLY_API_KEY" \
  -H "Accept: application/json"

Stop when hasMore is false. Keep the same window and filters on every page; changing them invalidates the meaning of the cursor.

The response repeats the effective window so an audit can record exactly what was queried:

{
    "items": [],
    "nextCursor": null,
    "hasMore": false,
    "window": {
        "from": "2026-07-07T00:00:00.000Z",
        "to": "2026-07-14T23:59:59.000Z",
        "generatedAt": "2026-07-14T12:00:00.000Z"
    }
}

A practical audit sequence

1. Query the full account window without type or state filters.
2. Group items by campaignId, leadId, and workflowInstanceId.
3. Separate provisional future entries from executed entries.
4. Inspect failed or rejected items with their reasonCode and reason.
5. For one prospect, compare the activity nodeId with the workflow graph in the campaign approval guide.
6. Only repair or approve content after confirming that the same workflow step does not already have a successful execution record.

Common errors

For the exact request and response schemas, open the endpoint reference for GET /v1/accounts/{accountGroupId}/activity under Accounts.