Become a provider
What video orchestration backends need to implement to integrate with Pipevideo as a provider.
This guide is for teams building a video orchestration backend that want to be listed as a provider on Pipevideo. End users integrate only with the Pipevideo API — your service is called by Pipevideo, not by customer applications directly.
What a provider does
A provider fulfills the heavy work of video generation after Pipevideo accepts a customer request:
| Stage | Responsibility |
|---|---|
| Orchestration | Run the customer's selected orchestration model to compose the video project from the prompt (and optional reference media) |
| Rendering | Produce the final video using a supported engine (e.g. HyperFrames, Lottie) |
| Artifacts | Optionally store secondary outputs alongside the video (e.g. source animation JSON, transcript logs) |
| Usage reporting | Return input/output token counts (and optional cost) so Pipevideo can bill the customer |
| Completion callbacks | Notify Pipevideo when a job finishes so the gateway can update status and fire customer webhooks |
How you implement orchestration, sandboxing, and rendering is up to your platform. Pipevideo does not document provider internals in customer-facing docs.
Integration model
Generation is asynchronous:
- Pipevideo creates a generation record and forwards work to your API with a
callbackUrl. - Your service returns an external job id and processes the request.
- On completion or failure, you POST to the callback URL with a signed payload.
- Pipevideo maps the result to the customer's
gen_...id and delivers webhooks if configured.
Your HTTP API should support at minimum:
- Create generation — accept engine, orchestration model, prompt, dimensions, and callback URL; return an external id.
- Status / poll (optional if callbacks are reliable) — return status, output URL, artifacts, and usage.
- Model catalog — orchestration models your provider supports per engine, for listing in
GET /v1/engines.
Pipevideo holds provider API keys and webhook secrets in its environment — customers never see them.
Provider contract (conceptual)
Each provider registers a slug (e.g. framerate) and declares:
supportedEngines— engine ids this provider can renderorchestrationModels— model ids and pricing metadata for the public catalog
When Pipevideo routes a request, it passes:
generationRequestId— correlates your job with the customer's generationengine,model,prompt,width,heightcallbackUrl— where to notify on completion
Your completion callback should include at least the external job id and terminal status. Pipevideo verifies callbacks with a shared secret (HMAC signature).
Catalog and routing
After integration, your provider appears in:
- The Providers sidebar and provider routing catalog
GET /v1/engines— engines and orchestration models- Customer
provider.orderrouting — e.g.{ "order": ["your-slug"] }
Customers choose providers through Pipevideo only. Do not ask Pipevideo customers to call your API directly unless they are building a separate integration with your product.
Next steps
Contact the Pipevideo team with:
- Provider name and proposed slug
- Supported engines and orchestration models
- Base URL for your provider API (staging and production)
- Webhook signing approach
Related
- Provider routing — how customers select a provider
- Webhooks — what customers receive when generation completes