Generation takes 20-60 seconds. The proxy returns 202 with a Retry-After header instead of holding the connection open. Subsequent requests for the same content-addressed URL stream from the edge cache in ~5ms.

To skip the polling, append ?wait_ms=8000 and the server long-polls up to 8 seconds before falling back to 202.

No. Asset IDs are content-addressed — same (src, motion, mode, dur, prompt, seed, idem, aspect) always produces the same asset_id and the same bytes. The mp4 is cache-control: immutable.

To intentionally vary output, change idem or seed. To replace the bytes for an existing asset_id, call regenerate — same URL, new bytes.

Two options:

1. Allowlist mode — list your origins; requests from elsewhere return 403.
2. Signed mode — embed signed URLs that expire. Without your signing secret, no one can mint new URLs.

See allowlist vs signed.

Only if you upload them via /api/v1/upload. Images fetched from public URLs are not persisted — only the generated mp4 + a poster jpg derived from them.

The vision model sees the source image, then returns a text prompt. Source pixels never round-trip back to disk.

Compositions linked to the project get unlinked (project_id = NULL) but stay around. Generated assets remain in R2 and are still served by the proxy URLs that point to them. The proxy key is invalidated; new requests with that key return 403.

To fully purge assets, contact support.

Not today. The model is picked from the project owner's tier — wan-fast / seedance / p-video. Custom models are on the v1.3 roadmap (BYO Replicate API key + model slug).

Free tier uses wan-fast, which doesn't natively support looped output. We crossfade the last 200ms back into the first frame in post — visible if you look closely. Pro+ uses seedance/p-video, which generate native loops with no seam.

The response carries X-Motioness-Loop: native | crossfade so your player can hide the seam (e.g. fade-in cover at the loop point).

Yes — request the .jpg poster, not the .mp4. Posters serve in ~5ms and are static jpg, perfect for og:image.

For animated OG (Twitter player cards, etc.), the mp4 works but make sure your hosting supports <video> in OG previews — most don't.

Proxy URLs are served from motioness.com. If a customer's adblocker blocks motioness.com, the mp4 won't load. The poster jpg falls back gracefully.

No third-party scripts run client-side (the SDK is your code, not ours), so the adblocker surface is minimal.

<video> doesn't work in most email clients. Use the poster jpg — same URL with .jpg instead of .mp4 — for static fallback.

For Gmail-style "preview a video", attach the mp4 as a separate URL and let the client render its own player when supported.

Rotating the secret invalidates outstanding signatures. Any webhook delivery in flight will fail signature verification on your endpoint until you update the stored secret. To avoid the gap:

1. Read both old + new secrets in your verifier during rollover.
2. Wait for retries to drain (max 2h).
3. Drop the old secret.