Build an n8n Product-Video Workflow with HTTP Requests and a Review Step

Prepare one input record

Give the workflow an approved brand, a stable request identity and the exact copy to render. Do not start with an unfiltered feed of ideas and let every incoming item trigger a paid job.

Our original record describes a small problem: a technician needs to know whether a replacement part is available before visiting a site. The approved text is: “Check the part before you book the visit.” A product reviewer must confirm that the app actually supports the action implied by that sentence.

Record the intended format and output count with that text. A batch of five messages should have five identifiable briefs, not one brief duplicated because the automation ran five times.

For this tutorial, use one piece. The API's larger permitted count is an input bound, not a recommendation for the first test.

Store authentication outside the workflow body

Prolifik API keys require an active paid plan. OAuth MCP trial access is a different route; it does not mean that a trial account can create the API key used here.

Configure the bearer credential through n8n's supported credential mechanism. Do not paste it into an article, shared workflow export, input table or ordinary text field that will be logged with each execution.

The creation workflow needs the current read and write scopes for content operations. Do not add publish:write merely because publication might be useful later. Write permission does not automatically include read permission, and content creation permission does not grant permission to post externally.

Use a read-only request such as the documented brand listing to confirm that you selected the intended account and brand. Check usage separately before creating the draft.

Configure the creation request

In HTTP Request, select POST and use the documented endpoint:

https://app.getprolifik.com/api/v1/content/jobs

Send JSON with the fields appropriate to the current contract. This is a request-body example, not a complete workflow export:

{
  "brandId": "REPLACE_WITH_OWN_BRAND_UUID",
  "format": "kinetic-type",
  "count": 1,
  "customTexts": [
    {"text": "Check the part before you book the visit."}
  ],
  "includeLogo": true,
  "deliveryMode": "download"
}

Provide a stable Idempotency-Key header for the intended creation operation. Preserve that identity with the exact approved payload. If the request times out, changing the key and sending another creation request can create duplicate work instead of recovering the first result.

The documented key lifetime is finite. An old key is not an indefinite duplicate-prevention database. Keep your own durable operation record and reconcile a known job before deciding to create anything again.

Save the job reference before waiting

Read the actual response and save the returned job identifier in a record that survives a failed n8n execution. The record should also include the brief identity, brand, format, payload identity, submission time and current review state.

Do not derive response-field expressions from this article's prose. Inspect the actual response and current API reference before mapping the field into the next node.

Once a job identifier exists, the next normal operation is a read:

GET /content/jobs/{jobId}

Use the same API base as the creation request. A successful creation response means that a job exists; it does not establish that a playable video exists yet.

Bound the status-check branch

Use an explicit wait and a bounded status-check branch rather than a tight loop. Choose the interval with the provider's current rate limits and your n8n execution design in mind. This tutorial does not promise a fixed rendering time.

The job's status and a piece's status serve different purposes. Check the expected pieces and returned media rather than treat any completed-looking job label as proof that every requested output is usable.

Review the file rather than the node's success color

Open the actual returned media. Confirm that the text is correct, the background is appropriate, the logo is the intended one and the composition remains readable on a phone. If you requested one piece, reconcile one piece before approving it.

Media URLs can expire. Keep the job and piece identifiers so you can retrieve fresh media through the supported read operation. Do not treat a signed URL copied into a spreadsheet as permanent storage.

This workflow stops before publication. A reviewed output can be handed to a human or a separate publishing flow with its own destination and timing authorization. deliveryMode describes intent; it is not evidence that a social post was sent.

Use the MCP-versus-API comparison if you are still deciding who should own this state handling. For the concrete requests, scopes and current limits, read the Prolifik API reference.