Shuffll Engage

07 / REST API

Your application.
A connected video workflow.

Connect your application to the operations your workspace allows. Start with capability discovery, use the current contract and keep generation and result handling explicit.

Updated October 22, 2026 · Shuffll Engage
APPLICATION / REQUEST
GET /api/v1/capabilities

Authorization: Bearer $ENGAGE_API_KEY

Keep credentials on your server
ENGAGE / CONTRACTDiscover first.
Call what is supported.
Access
Authorized workspace
Operations
Current capabilities
Release
Fixed-video V1

Discover the available contract

The Engage REST base URL is https://engage.shuffll.com/api. Operation paths include the version prefix, such as /v1/capabilities. Authenticate using the Engage key issued for your integration and read the available capabilities before building a workflow around them.

Requests are governed by workspace access and policy. Keep credentials in your application’s server-side secret storage. The separate Shuffll video-production API has its own contract and credentials; it is not interchangeable with Engage.

Open the API contract ↗

Follow work through to a result

The documented V1 workflow starts with an authorized, ready published template version. Create a campaign, prepare recipients, request generation explicitly and follow the returned job until it reaches a terminal state. Then inspect the available video results.

Use the operation’s documented idempotency and revision requirements for writes. For an uncertain retry, preserve the identity of the original operation and its input. Follow job polling guidance, and distinguish complete, partial and failed outcomes in your application.

Match the release to the experience

API V1 is the fixed-video contract.

Adding recipient records does not personalize rendered media in this release. Full creative authoring, behavior-based video variation, product-video rendering, message sending and customer webhook subscriptions are outside the documented V1 contract.

These limits belong to the API release; they do not define the whole Engage workspace. Discuss a workflow that needs additional capabilities with Shuffll, then verify the supported interface before implementation. The platform overview explains how the broader pieces fit together.

QUESTIONS, WITH CONTEXT

Go one question deeper.

Explore the details that matter for this part of the workflow.

API access and discovery

Start with a scoped, supported connection.

Which base URL should an Engage REST integration use?

Use https://engage.shuffll.com/api and append the versioned operation path from the reference. For example, the complete capability-discovery URL is https://engage.shuffll.com/api/v1/capabilities. The documentation website is not the API request host.

Link to this answer ↗
Can I reuse a Shuffll video-production API key for Engage?

Engage and the separate video-production API have different contracts and credentials. Use the authorized Engage key issued for the intended workspace and integration, and keep it in private server-side storage.

Link to this answer ↗
Why should my application discover capabilities first?

Available operations depend on the workspace, permissions and current policy. Capability discovery helps the application work from the access it actually has instead of assuming every documented operation is enabled for every principal.

Link to this answer ↗

Campaigns, jobs and retries

Track explicit actions through to their outputs.

Does creating an API campaign immediately generate videos?

No. Generation is an explicit operation in the documented workflow. Prepare the campaign and its recipients, satisfy the operation requirements, then request generation and inspect the resulting job.

Link to this answer ↗
How should an integration handle a request with an uncertain outcome?

Follow that operation’s idempotency and revision contract. Preserve the original operation identity and input for an uncertain retry, then inspect the existing result or job. Do not turn an unknown outcome into a new generation request by default.

Link to this answer ↗
How do I know when a generation job is finished?

Follow the returned job and its documented polling guidance until it reaches a terminal state, then inspect the available results and failures. A finished generation job does not establish that a recipient received or watched a message.

Link to this answer ↗
Product and release scope

This guide describes workspace capabilities and documented implementations. Availability depends on deployment, workspace configuration and the integration contract. Confirm the required features for your rollout with Shuffll.

Public API + MCP documentation ↗

YOUR AUDIENCE. YOUR NEXT CHAPTER.

See the workflow
with your own use case.

Start the conversation ↗