Skip to Content
DocsUser GuidesCampaign delivery

Campaign delivery

Workbench manages delivery campaigns (email, SMS, WhatsApp, schedules, and agent-assisted outreach). That layer is separate from Runtime scoring campaigns (campaign / subcampaign on POST /invocations).

LayerWhat it isTypical API
Delivery campaignBusiness overlay: audience, channels, content, schedules, runsWorkbench /api/v1/campaigns and Public API — Campaigns
Scoring deploymentPredictor pushed to RuntimePOST /invocations → POST /response on the Runtime host

Runtime channel values such as app, web, or api describe the scoring context. Delivery channel catalog entries (email providers, WhatsApp, …) live on the Workbench campaign document.

Operator surfaces

SurfaceUse for
Campaign manager (Intelligent Sales)Edit campaign documents, channels, schedules, and triggers
Custom FormsCapture structured inputs linked to campaign workflows
Data Management & CampaignJoin audience data with campaign entities
Time Process CampaignTime-based process steps on a campaign graph
Campaign Management serviceAgentic campaign ops when ecosystem-campaign-management is deployed — see Claude Agent — Campaign Management
Campaign Outreach AgentBuild/configure/run outreach via MCP tools (sample_run, test_target_email) — Workbench MCP

Campaign process workflow

A typical end-to-end campaign process (business overlay + technical execution) looks like this:

  1. Plan audience, content, and channels on the campaign document (or with the Campaign Agent / Outreach Agent where enabled).
  2. Wire delivery channels — GET /public/v1/campaigns/channel-catalog, then set selection with PUT …/channel-selection (Public API).
  3. Validate before live send — prefer a dry or sample run first:
    • Outreach MCP: run_outreach_campaign with sample_run and optional test_target_email (MCP tool table).
    • Inspect GET /public/v1/campaigns/runs/{run_id}/progress before promoting to production traffic.
  4. Trigger with POST /public/v1/campaigns/{campaign_id}/trigger or arm schedules via POST …/schedules/sync.
  5. Monitor runs (GET …/runs, GET …/runs/{run_id}) and stop if needed (POST …/runs/{run_id}/stop).
  6. Where a deployment is linked, closed-loop scoring still uses Runtime POST /invocations then POST /response.

Changing delivery schedules does not replace pushing or testing a deployment. Use Deployment Test or Runtime Testing for predictor behaviour.

HTTP API summary

Full tables: Public API — Campaigns. Private /api/v1/campaigns mirrors campaign CRUD, _generate helpers, and operator triggers (Private APIs).

Entity collection name on the public gateway: campaigns (see Entity collections).

Last updated on
MonitoringIntroduction