Skip to main content
A run is one execution of a flow. The API creates runs asynchronously — POST /runs returns an ID immediately, and you poll GET /runs/:id until the run completes and produces a final video URL.

Lifecycle

A typical run takes 30 seconds to 5 minutes, longer for flows with multiple video generations.
Runs resume automatically across server-side timeouts. If a processing tick hits its wall clock mid-run, the next tick detects the stale heartbeat and picks up from the last completed step.

POST /runs

Create a new run.
string
required
Bearer hck_live_<prefix>.<secret> — must carry runs:write scope.
string
A UUID (or any opaque string) that the server keys retries on. Two requests with the same (user_id, Idempotency-Key) return the same run instead of creating a second one. Strongly recommended for every POST.

Body

string (uuid)
A saved flow ID from GET /flows. Mutually exclusive with flow_schema.
object
An inline FlowSchema JSON object — the same structure the visual editor saves. Use this when you want to run a flow without persisting it. Mutually exclusive with flow_id. See flows for the full shape.
object
Run an Influencer Studio content mode for one of your projects. The influencer’s saved reference images are wired in automatically. Mutually exclusive with flow_id and flow_schema.Provide the mode’s runtime inputs via inputs — e.g. the driving video (avatar) or product image (ugc) as an inputs.media entry (keyed by the media_input step’s step_order), and any scene/script prompts via inputs.prompts. The influencer reference shots are pre-filled, so you only supply what’s unique to the run. The finished video is returned on the run’s video_url like any other run.
object
Caller-supplied overrides that fill in the flow’s placeholders. See inputs reference for the full schema.
string
Alternative to the Idempotency-Key header — the body field wins if both are present.

Response

string (uuid)
required
The new run’s ID. Use this for polling, listing, and cancellation.
string
required
Always queued on a fresh run. completed or other statuses can appear on an idempotency-retry if the prior run already finished.
string (ISO 8601)
required
UTC timestamp.

GET /runs/:id

Fetch a single run’s current state. This is the polling endpoint.
string (uuid)
required
Run ID returned from POST /runs.

Response

string
required
string
required
queued | running | completed | failed | cancelled.
integer | null
Zero-indexed step currently being processed (or last completed). null until the worker picks up the run.
string | null
Public URL to the rendered MP4 on video.hyperclip.co. Populated once status === "completed". The file stays hosted at this URL permanently.
string | null
Machine-readable error category. See error codes.
string | null
Human-readable error detail.
integer
Total credits billed so far for this run.
string (ISO 8601)
required
string | null
Set when the worker first claims the run.
string | null
Set on completed, failed, or cancelled.

GET /runs

List the authenticated user’s recent runs.
integer
default:"20"
1–100.
string
Filter to a single status: queued, running, completed, failed, cancelled.

POST /runs/:id/cancel

Cancel a queued or running run. The worker respects the cancel flag between steps — any in-flight provider call (image, video, audio generation) still completes and bills naturally.
string
required
string
required
cancelled on success.
A run that already finished returns 404 run_not_cancellable. Cancellation is only valid for queued or running states.

Polling strategy

The SDKs ship a built-in runs.wait() helper. For raw HTTP, write your own loop following the same shape.

Recommendations

  • Poll every 3–5 seconds. Less than that wastes requests; more than that adds lag.
  • Back off to 10s after 2 minutes of runtime for long video flows.
  • Never poll from the browser with your API key attached.
  • Cancel runs that exceed your expected duration — stuck worker ticks eventually time out anyway, but an explicit cancel releases credits faster.

Idempotency in depth

When you send Idempotency-Key: <uuid>:
  1. If no run exists for (user_id, key) — a new run is created.
  2. If a run already exists — the server returns that run’s current state without creating a new one.
Keys are scoped per API-authenticated user. Different users sending the same key create independent runs.
Pick your idempotency key carefully. Reusing a key across semantically different requests means the server returns the wrong run’s state. One key per logical retry sequence.