Skip to main content
An autopilot turns what is trending in a Brand’s niche into finished, scheduled content. Each run picks a trend, researches it, writes a fact-checked script in the Brand’s voice, makes the video, writes a native version for every destination and schedules the posts — pausing for approval wherever you choose.

Before you configure it

An autopilot belongs to one Brand. The minimum setup is:
  1. Create a Brand with POST /v1/brands, or copy brands[].id from GET /v1/brands.
  2. Decide whether the workflow should publish anywhere.
  3. Configure the autopilot with PUT /v1/autopilots/{brandId}.
You can use autopilot without any connected social account. Send "destinations": []; Sigmora researches, writes, and makes the asset, then stops before publishing. Publishing needs one interactive step: a workspace owner connects the social account and selects its publish target in the dashboard. That gives you the productTargetId used below. Never guess this id or send a social password. Each publishing destination also names a productId: create the product with POST /v1/products and copy product.productId from the response (not product.id, which addresses the product record). If nothing is promoted, run without destinations.

Configure one Brand

productTargetId refers to the publish target selected in the dashboard; productId comes from POST /v1/products or GET /v1/products. An empty destination list is valid: the run generates the asset and stops without claiming it posted anywhere. Autonomy modes:
  • draft_only researches and writes, then asks before rendering;
  • review_first renders and adapts, then asks before distribution;
  • full_auto runs through scheduling, subject to caps and quiet hours.
Every mode still fact-checks the script and follows the Brand’s saved voice, product, and safety rules. full_auto removes the ordinary human approval checkpoint; it does not turn a non-publishable fact-check result into an approved asset. The response includes creditQuote, the most a run can reserve, so you can show it before turning the autopilot on. It is built from these lines: For example, a generated video with no destinations quotes 410 credits. Sending it to YouTube and TikTok quotes 450. Supplying source clips changes the video line from 300 to 150.

Start the complete workflow

When no topic or trend id is supplied, Sigmora selects the highest-ranked observed trend matching the Brand’s primary theme. You can instead send a specific trendId from GET /v1/trends, or a manual topic. The endpoint returns 202 and a durable run id. The run then:
  1. selects and stores the trend evidence;
  2. performs topic research using the configured research providers;
  3. writes in the Brand voice and includes only products relevant to the topic;
  4. edits supplied clips, or generates a narrated faceless video when no clips were supplied;
  5. waits for the generated video URL before distribution;
  6. writes a distinct platform-native caption and hook for every destination;
  7. carries the resolved media URL into each queued post;
  8. schedules each destination and records publish/measurement join keys.
Idempotency-Key is required. Repeating the same request returns the same run; reusing the key for different input returns 409 conflict.

Metering and settlement

Before POST /v1/autopilot-runs returns 202, Sigmora atomically reserves the whole creditQuote.totalCredits from the workspace wallet. If the balance cannot fund the quote, no run is created and the API returns:
The run’s billing object is the audit record. It contains every quote line, reservation and refund reference, balance after reservation and settlement, and aggregate reserved, spent, and refunded credits. Settlement follows delivered value:
  • a completed metered step consumes its quoted line;
  • skipped, gated, failed, or never-started lines are refunded;
  • a failed/capped run that produced no script, video, or platform adaptation receives a full refund;
  • when a usable deliverable exists, only its completed lines remain charged;
  • an approval keeps the original reservation and does not debit again;
  • a retry creates a new, separately idempotent billing attempt;
  • replaying the original Idempotency-Key never creates another reservation.
Charges and refunds are idempotent. If a refund cannot be completed straight away it is retried automatically, and the run shows billing.status: "refund_failed" until it succeeds.

Observe, approve, and recover

The run resource contains its current phase, every observed step, generated video and publishing ids, selected trend, pending approval, billing quote and settlement, spend estimate, and failure detail. Approval resumes the same saved run. Retry is accepted only for a failed or capped run and also resumes from its last completed step, so completed paid steps are not repeated. A paused autopilot (enabled: false, also the default when a configuration is saved without it) runs nothing: starting a run, approving a checkpoint and retrying answer 409 conflict until you set enabled: true, as they do while the workspace’s Governance kill switch is on. Approvals have a time limit. The default is to keep waiting; configurations may approve automatically or discard the run after the chosen number of hours. Any approval older than seven days is rejected as a hard backstop. An enabled autopilot starts a run on its own each time runIntervalMinutes has elapsed. During distribution, build_campaign creates the durable campaign shared with the dashboard and returns its id in the step output. Read the campaign and its actual scheduled posts with GET /v1/campaigns/{campaignId}. See Campaigns.