# How to plan a Shuffll Engage video campaign integration

Start an Engage integration by defining the audience, the video content that should vary, and the business workflow that will use the results. Then match those requirements to the operations, template inputs, and access available in your workspace. Use REST from application code or MCP from a compatible AI assistant.

This guide is a planning checklist. The [REST operation contract](/engage/openapi) defines request fields; the guide does not introduce new API parameters or certify a connector, rendering format, or delivery channel.

## 1. Define the campaign outcome

Write down who should receive the video, why the content is relevant to them, and what should happen after the video is ready. Customer interests, behaviors, and audience segments can inform the brief. E-commerce and product videos are examples within that broader customer-journey focus.

Keep audience rules, content rules, and delivery rules explicit. For example, selecting recent customers is an audience rule; choosing approved content for a segment is a content rule; sending a message is a delivery rule. Each needs its own supported implementation.

## 2. Map the data you will need

| Data category | Planning example | Integration decision |
|  --- | --- | --- |
| Recipient identity | Your external customer ID | Map to the documented recipient identity without assuming IDs transfer between APIs |
| Audience selection | A business-defined segment | Decide where the rules run and which selected records reach the campaign |
| Content inputs | Approved copy or template variables | Confirm that the chosen rendering workflow accepts and uses these inputs |
| Brand assets | Approved imagery, logos, and other media | Confirm ownership, accepted formats, and the supported template settings |
| Delivery destination | A configured customer contact or channel | Verify channel access and the delivery operation separately from rendering |
| Missing data | A recipient without a required content value | Define an approved fallback or hold rule before a real campaign runs |


These examples describe planning categories. Send only fields accepted by the selected operation. In particular, do not add invented personalization fields to the legacy recipient API.

## 3. Choose REST or MCP

| Connection | Use it when | Start here |
|  --- | --- | --- |
| Engage REST API | Application code or an automation service will make requests | [REST quickstart](/engage/quickstart) |
| Engage MCP | A compatible AI assistant will discover and call authorized tools | [MCP setup](/engage/mcp) |


REST and MCP connect to Engage. They do not remove workspace access requirements or change a rendering format's capabilities. If your task is creating and exporting an individual video project, compare the separate [Video Production API](/choose-api).

## 4. Confirm the rendering workflow

Read live capabilities, inspect the selected template and version, and establish the input contract for the output you want. The documented legacy `flat-video-v1` operation renders fixed clips; importing names, contact details, or segment membership alone does not make its media personalized.

For a workflow intended to vary video content, verify that the relevant inputs actually affect representative rendered results. A tool listing, successful authorization, or accepted job does not prove this behavior. See [API scope and availability](/engage/release-status).

## 5. Test results before extending the workflow

Use synthetic audience records for integration testing. Select representative cases, including missing data and different configured content branches. Request generation explicitly, follow the returned jobs, and inspect the final video results.

Check the scope of the evidence: authorized request, accepted work, successful rendering, correct media variation, and completed delivery are different checkpoints. The [jobs and retries guide](/engage/errors) describes how to handle asynchronous work and uncertain retries.

## 6. Keep generation and delivery observable

Retain the campaign identifier, current revision, operation or idempotency value, job identifier, and the resulting status. Use the documented retry rules and avoid issuing a second generation request just because an earlier response was uncertain.

If delivery is part of the campaign, confirm the separate operation and channel configuration, then inspect its own result. Rendering success alone does not establish delivery, message engagement, or attribution.

## What should I share with the Shuffll team?

Share the intended audience rules, which media should vary, the preferred REST or MCP connection, the template or workflow under consideration, and the environment you plan to use. Include operation and request IDs when troubleshooting. Exclude credentials and personal recipient data.

Use the [API FAQ](/faq) for common questions or [contact Shuffll](/contact) to confirm workflow-specific access and deployment details.