An accepted video job is not a finished video. A carousel can teach that distinction to a content team without making everyone read an API reference, but each card must keep the job identity, state and next action straight. The common mistake is to draw a smooth four-step progress line that has no failure or review branch.
The existing video-MCP job-status guide is a troubleshooting reference for someone checking a real job ID. This page is a visual-explanation brief: how to turn an asynchronous workflow into cards that make the distinction impossible to miss.
Choose one job type before drawing the states
Prolifik has different long-running workflows. Clipping jobs, content jobs, individual pieces and Studio generation use their own resources and terminal states in the current REST documentation. A card labeled “video job complete” cannot safely mix them into one universal state machine.
Suppose a fictional marketing team called CedarLab has started a content job from an approved product brief. The team wants a short educational carousel for colleagues who ask why an API call returned successfully but no media is ready in the library. Its example is explicitly illustrative. The real product documentation should supply the exact endpoint and status labels when the team publishes an implementation guide.
| Card | Message | Evidence to keep |
|---|---|---|
| Accepted | The service received a request and returned an identifier. | A job ID, not a finished media URL. |
| Working | The job is still processing. | A current status read for that same ID. |
| Ready to review | A piece or output is available for inspection. | The returned asset and its review state. |
| Failed or partial | Work stopped or some outputs failed. | The error and which items, if any, succeeded. |
| Published | A separate public write was confirmed. | The destination post or schedule record. |
These are educational categories, not literal status enum values for every Prolifik endpoint. The published carousel should link to the current API or MCP documentation for the exact values used by that job type.
Keep the identifier attached to every state
When the team starts several jobs, a status screenshot can be copied into the wrong discussion. The carousel can use one fictional identifier shape throughout, but never show a real customer ID or API key. An actual internal training card should include a safe job reference so a reviewer can tell which request was read.
Do not show a success state from a different sample job merely because it looks clean. The causal story is: create response for job A, later status read for job A, output retrieved for job A. If the first request was retried, the team must know whether the retry reused an idempotency key or created a second job. The duplicate-job guide handles that operational issue in detail.
Keep a source note for the cards. A status illustration that looks like a real dashboard can mislead a reader into treating it as a screenshot. Use controlled text and clearly conceptual artwork if the example is not actual product UI.
Draw the branch, not only the happy path
An accepted request may fail or produce partial output. A carousel with only “accepted, rendering, done” can teach the wrong operational habit: keep polling forever or publish whichever file appears first. Show the failure branch and the action it requires.
For CedarLab, card four could say “If a piece fails, read the reason and keep the successful pieces separate.” It should not say “Try again until it works” without checking whether a retry creates billable work or duplicate content. The current Prolifik API docs distinguish retry behavior and idempotency; consult the exact endpoint before adding instructions.
The public audience may not need every internal state. Keep the educational claim modest: a create response is a receipt, a later read determines whether media is ready, and publishing is a separate decision. That distinction is useful even when a product renames its state labels.
Match visuals to the documented product contract
The Prolifik REST API reference lists long-running work by resource and terminal condition. It says clipping, rendering and generation can take time and require polling. The MCP guide exposes tools over the same service code and plan limits but is a different client interface. Do not turn a diagram into a claim that every client exposes every operation.
If the team wants to show actual data, use a sanitized response from a test job and verify it against current source. Put exact JSON fields in editable text. Generated art can carry a progression motif, not the status value itself.
For a training carousel, include a link to the page where an operator can actually check the job. A final card that says “Your video is live” is wrong unless someone has performed and verified the separate publish step.
Produce the cards and read them independently
Prolifik Image Carousel can create branded panels and a timed video from approved copy. Supply the sequence, status caveat, failure branch and source link in the brief. Inspect every returned card. If a generated caption changes “ready to review” to “published,” reject it. The two states have different consequences.
Watch the timed version at phone size. The job ID or safe reference should remain readable where needed, but a dense API response need not fill the frame. Keep the branch visible long enough for a viewer to see that failure is a possible outcome, not a decorative side note.
Then inspect the post destination separately. A correct educational carousel in the library is not proof it has been scheduled or published. Keep the approved file, live URL and date with the source documentation used for the status names.
Keep the job states separate on every card
Give the generator approved status copy and inspect the returned sequence.
Explore Image CarouselFacts checked 2026-11-02. Worked examples are illustrative unless a real source is identified.
- Prolifik: api Checked 2026-11-02
- Prolifik: mcp Checked 2026-11-02
- Prolifik: image carousel Checked 2026-11-02