Long-running processing
Video mocap jobs can outlive a normal HTTP request, so polling and terminal state handling are safer than synchronous conversion semantics.
MOCAP API
Async mocap API job workflow
Understand the async job lifecycle for AIMoCap API jobs: create, upload, complete, poll, and download.
For developers who need a non-blocking mocap API workflow.
Short answer
An async mocap API separates job creation, upload, queue admission, processing, polling, and download so clients do not hold one request open for the full solve.
When to use AIMoCap
Use AIMoCap's async flow when your application needs reliable job state transitions, retry boundaries, and downloadable artifacts after processing completes.
When not to use AIMoCap
Do not use the async API as a synchronous conversion endpoint or assume a created job has consumed v-credit before source validation and runner preflight complete.
Async mocap API searches are more engineering-specific than broad AI mocap API searches. The main question is how to run long video-processing jobs without blocking a client request.
AIMoCap splits the workflow into explicit phases: create a job, upload the source, complete the upload, wait for queue processing, poll status, and download results.
This lifecycle matters because each stage has a different failure mode. A client should treat upload errors, queue limits, source validation failures, processing failures, and completed artifacts as separate outcomes.
Async API state boundaries
- Job creation and queue admission are separate steps.
- Upload failure should be handled before a job is considered processable.
- Clients should poll status and handle queued, processing, completed, and failed states.
- Result URLs are only useful after the corresponding artifact is ready.
- API v-credit is charged around validated processing, not merely because a client opened a create request.
- A retry strategy should distinguish upload retry, complete-upload retry, status polling, and result download retry.
- The async flow is designed for product integrations, not real-time live capture.
Why async state modeling matters
Use these facts to decide whether this workflow matches your output, integration, and cleanup needs.
Clear failure ownership
Upload, validation, runner preflight, algorithm processing, packaging, and result download failures require different user messages and retry behavior.
Ledger clarity
API v-credit should map to validated processing work, which is why the lifecycle should not be collapsed into a single opaque call.
Async mocap job lifecycle
01
Create a pending job
Send title, target IDs, optional trim fields, and export FPS. The response gives the client a job ID and upload path, but the job is not useful until the source upload is completed.
02
Upload and complete source
Upload the video to the returned upload URL, then call complete-upload. AIMoCap validates the object and admits the job to the queue only after the upload is complete.
03
Poll terminal status
Poll the job status instead of blocking the original request. Download preview, FBX, robot JSON, or other available artifacts after the job reports completed.
Common questions
Why is the AIMoCap API asynchronous?
Video mocap is a long-running job. The async flow lets clients upload, queue, poll, and download results without keeping a single request open for the full solve.
When should a client start polling?
Start polling after the source upload is completed and the job has been admitted into the processing flow. Before that, upload or validation errors should be handled directly.
What should the client do when a job fails?
Show a stage-aware error when available, avoid treating failed jobs as downloadable results, and let users retry from the appropriate stage instead of silently creating duplicate work.
Is async mocap API billing separate from Studio billing?
Yes. API jobs use API v-credit and should appear separately from web Studio credit usage.
Related AIMoCap guides
Continue through this topic cluster to compare output formats, API options, and workflow boundaries.
Sources reviewed
Competitor details are summarized from public official pages and public community or review discussions. Community feedback is treated as directional signal, not as a universal product claim.