Separate “submit this approved video brief” from “check whether its video is finished.” In Make, those can be two scenarios that share one durable operation record. That arrangement makes a later status check a read, instead of another paid creation request.
This tutorial uses Make's HTTP modules and Prolifik's documented API. It does not require or claim a publicly available native Prolifik directory app. The design is an original implementation recipe, not an imported scenario or a live generation benchmark.
The example turns an approved sentence for a fictional workshop-booking app into one Text Story. No real credentials, customer data or publication action are included.
Define the record both scenarios will share
Use a durable store suited to your Make setup. The important property is that a later scenario can identify the exact creation operation and its returned job, including after an interrupted run.
An original record design is:
| Field | Purpose |
|---|---|
| Brief identity | Identifies the specific approved message and version. |
| Payload identity | Ties the request to the exact brand, text, format and count. |
| Idempotency key | Identifies this intended write within the API's supported window. |
| Job identifier | Lets the second scenario read the existing job. |
| Submitted time | Supports reconciliation and an explicit waiting limit. |
| Expected piece count | Makes missing outputs visible. |
| Last observed state | Separates pending work from a failure or completed review. |
| Review decision | Keeps media retrieval separate from approval. |
These are your integration's record labels, not Prolifik response enums. Match the actual API fields when mapping the returned identifier and status.
For the workshop app, the approved sentence is: “Choose a session before you reserve a seat.” A product owner must confirm that it matches the real booking flow. The automation should not improve the copy by inventing availability, discounts or guaranteed outcomes.
Scenario one submits only approved work
Start from a record explicitly approved for creation. Reject a record with missing brand identity, unresolved copy or an already-linked active job before calling the API.
Use Make's HTTP “Make a request” module for the current documented endpoint:
POST https://app.getprolifik.com/api/v1/content/jobs
Configure the bearer API credential in Make's dedicated credential storage. Keep it out of the data record, public request examples and shared scenario exports. Prolifik API keys require a paid plan; MCP OAuth trial access is not API-key eligibility.
Send JSON appropriate to the current content contract. For example:
{
"brandId": "REPLACE_WITH_OWN_BRAND_UUID",
"format": "kinetic-type",
"count": 1,
"customTexts": [
{"text": "Choose a session before you reserve a seat."}
],
"deliveryMode": "download"
}
Send the required Idempotency-Key for this operation and save the exact payload identity with it. Store the returned job identifier before the scenario marks its submission work complete.
Do not request publication permission for a creation-and-review-only integration. Use the current content read/write scopes as needed, remembering that a write scope does not automatically include read access.
Scenario two reads existing jobs
The second scenario selects records with a known job identifier and unresolved output. It reads:
GET /content/jobs/{jobId}
Use Prolifik's same API base and appropriate read credential. This is not another POST /content/jobs, and it is not a webhook notification. Polling is an explicit integration choice here.
Read the current job and piece states. A job can still be processing, contain ready pieces or report a partial failure. Decide what the scenario should do with each condition before enabling it on a schedule.
Keep a bounded total wait or an escalation date in the record. Repeatedly observing the same pending state should not cause the scenario to create a replacement job automatically.
Handle an uncertain submission without guessing
Consider an interrupted first scenario. The HTTP request may have reached the server even though Make did not save the response. That is different from a confirmed validation error that created no job.
Preserve the operation's payload and key. During the API's documented idempotency window, the same intended request can be reconciled under its supported semantics. Do not reuse that key with different data, and do not assume the key protects you indefinitely after its retention window.
If the result remains uncertain, stop and reconcile it through the supported job listing and request evidence. A second new operation is a new production decision, not a harmless readback.
The video-agent duplicate prevention guide explains that distinction in more detail. Check the retry contract for the specific operation rather than assume every endpoint behaves identically.
Count usable pieces before approving the record
For this example, success means one expected piece with a ready state and playable media, followed by an actual human review. A successful HTTP module, an accepted job and a finished usable video are three separate observations.
Save the piece identifier, not only a signed media URL. If the URL expires, retrieve fresh media using the supported read path. Do not label a record “approved” merely because the URL field is populated.
Inspect the whole clip: text, background, timing, logo and phone-sized legibility. If a revision creates another render, inspect that new file rather than assuming the first approval transfers to it.
Keep publication outside this first scenario pair
The two scenarios deliberately stop at a reviewed draft. A separate publication operation needs the chosen account, caption, timing and explicit authorization, plus the relevant publishing scope.
Do not describe deliveryMode: "download" as a security boundary. It communicates the job's delivery intent; actual external publication is controlled through distinct endpoints and permissions. The absence of publication permission is the stronger technical separation for this design.
Use the Prolifik API reference for the current payload, scopes, limits and returned fields. If you prefer a conversational workflow to maintaining scenario state, compare the responsibilities in MCP versus API video generation.
Build against the documented video API
Check authentication, input contracts and job readback before you automate creation.
Read the video API referenceFacts checked 2026-10-24. Worked examples are illustrative unless a real source is identified.
- Make HTTP documentation Checked 2026-10-24
- Prolifik API reference Checked 2026-10-24
- Prolifik MCP reference Checked 2026-10-24