Skip to main content

Campaign

Current source defines Campaign as an authenticated marketing surface for campaign records, audience conditions, channel content, schedules, and delivery counters. This guide documents fixed-source behavior only; it does not prove that Campaign is enabled or deployed for a project, that an audience is accurate, or that a message is sent.

Do not operate Campaign for documentation

Opening the surface reads private campaign data, and opening a campaign can submit its conditions to the audience endpoint. Create, save, cancel, delete, condition, and content controls can persist records, select recipients, queue work, or affect outbound delivery. Do not use real recipients, audiences, provider credentials, messages, URLs, schedules, or production campaign records.

Availability and navigation​

The /marketing/campaign route is restricted to level-0 administrators, but the route does not repeat the Campaign feature check. The sidebar additionally requires the Marketing parent—an eligible Pro or Enterprise project, level 0, and no read-only state—and the marketingCampaigns feature flag for the Campaign item. Route access, parent visibility, item visibility, API authorization, and the API's source-defined project gate are independent conditions.

Campaign controls with no campaign rows or audience data

Authenticated reads and automatic audience evaluation​

The list source performs an authenticated, paginated campaign request on mount and can search by campaign name or contact type. Campaign detail source can read the selected campaign, its conditions and delivery counters, plus Pro configuration categories used by the form.

Opening a populated campaign can also POST its current conditions and contact type to the audience endpoint. That response can contain recipient records and pagination, so this is neither a harmless local preview nor a safe read by HTTP verb. None of these requests was executed for this documentation.

Source-defined record and channel states​

The source models email, SMS, WhatsApp, notification, popup, and webhook contact types. Campaign data can include a name, contact type, channel-specific content, audience type, conditions, schedule, end time, status, counters, and recipient events.

Although the record contract accepts all six contact types, the inspected launch job dispatches per-recipient work only for email, SMS, notification, and webhook. Its WhatsApp and popup branches are empty, so those accepted enum values are not delivery or job evidence.

Current API source defines these important boundaries:

  • campaign creation is restricted by a literal project-code gate in the inspected source;
  • contact type is required on creation and cannot be changed by the update path;
  • ended and canceled campaigns reject updates, while an active campaign accepts only cancellation;
  • creation requires at least one audience condition, and a fixed audience cannot be empty;
  • scheduling can change the initial status and delay a queued launch job, but source does not prove hosted timing or delivery.

The Dashboard's local status changes and success toasts do not establish that the deployed API accepted the payload or that a provider processed it.

Persistent and outbound effect surfaces​

Current Dashboard and API source define the following effect classes:

  • create a campaign and its condition rows;
  • calculate an audience by POST and, for a fixed audience, persist recipient relationships;
  • dispatch a campaign-launch job immediately or with a source-calculated delay, with inspected per-recipient branches only for email, SMS, notification, and webhook;
  • update general, schedule, audience, and channel-content fields;
  • create or delete individual conditions;
  • cancel or delete a campaign and invoke plugin hooks/actions;
  • read recipient delivery events such as sent, opened, bounced, complained, unsubscribed, or clicked states.
Cancellation has a broad fixed-source risk

The inspected API cancellation path deletes unsent campaign-recipient rows without scoping that deletion to the selected campaign. No hosted execution or affected-row boundary was tested. Do not cancel or retry a campaign until a corrected deployment is proven by immutable serving evidence and a synthetic, isolated fixture.

Privacy and provider boundaries​

Campaign names, conditions, recipient records, email addresses, phone numbers, channel content, provider settings, credentials, webhook or redirect destinations, schedules, tracking identifiers, and delivery events are private or secret-adjacent operational data. Provider configuration checks and plugin hooks can cross system boundaries. Do not copy any live value into screenshots, tickets, chat, logs, or documentation.

What remains unverified​

Without immutable Dashboard/API serving receipts and a credential-free synthetic campaign fixture with intercepted egress, this page does not claim:

  • that Campaign is available for any hosted project;
  • that audience calculation, validation, scheduling, cancellation, or deletion is correct or isolated;
  • that a job was queued, started, retried, canceled, or completed;
  • that any email, SMS, WhatsApp, notification, popup, webhook, or provider action occurred;
  • safety, idempotency, rollback, recipient accuracy, delivery timing, or success.

Related guides: Marketing overview · Advanced offers