Replicate made it easy to call one model behind one endpoint, but most production pipelines outgrew that shape: you end up stitching three or four per-model calls together in application code, paying for cold starts on each hop, and debugging JSON payloads you can never see. A canvas API flips that model. You build the pipeline visually, run it once to confirm the output, then call the whole graph as a single REST endpoint. Wireflow is built around exactly this pattern, which means chaining an image model into an edit model into a video model happens on the canvas rather than in your codebase. This guide walks through the migration step by step.
Why teams move off Replicate
The common trigger is not one big failure, it is accumulated friction. Replicate bills per hardware-second, which is nearly impossible to forecast once traffic scales, and the Replicate pricing breakdown shows how quickly A100-seconds add up across a multi-step pipeline. Cold starts range from a few seconds to well over a minute depending on model size, and every model in your chain pays that penalty independently.
The structural issue is bigger than cost. Replicate gives you per-model endpoints, so a product-photo pipeline (generate, edit, upscale) means three network round trips, three polling loops, and three failure modes that your application code has to reconcile. There is no way to test a change to step two without redeploying code. If you want to see what migrating this kind of pipeline looks like end to end, the migrate from Replicate to a canvas API feature page shows the before-and-after in one view.
What a canvas API actually changes
A canvas API keeps the REST surface you already know but moves pipeline definition out of code and onto a visual graph. Nodes are models or utilities, edges are data flow, and the entire graph executes as one unit through a single API call. An AI canvas API gives you two things Replicate never did: you can see intermediate outputs at every node while you build, and the orchestration logic (which output feeds which input) lives in the graph instead of your application.
The practical consequence is that debugging changes character. Instead of logging base64 blobs to figure out why step three produced garbage, you open the canvas, look at what node two actually emitted, and fix the connection or the prompt in place. Teams that run multi-model AI workflows report that most iteration stops touching code entirely; the code only ever calls one stable endpoint.
Prerequisites
Before migrating, gather three things. First, an inventory of your current Replicate calls: which models, in what order, with which parameters. Second, an account with an API key, generated from Settings > API Keys in the dashboard (keys start with sk- and are shown once). Third, a sense of your execution volume, since plan tiers cap daily executions; the pricing page maps volume to plan.
Step-by-step migration
Step 1: Map your Replicate chain to nodes
List every replicate.run() call in sequence and note what output feeds what input. Each call becomes one model node on the canvas. A typical text-to-image call maps to a generate:flux_2 node, an image edit maps to edit:nano_banana_pro_edit, and image-to-video maps to video:kling_video_2_5_i2v. The full node catalog covers 157 nodes across generation, editing, video, audio, and utilities, documented at /docs/nodes. The glue code between your Replicate calls (passing URLs, waiting on polls) disappears; it becomes edges.
Step 2: Rebuild the pipeline on the canvas
Create the workflow visually, or programmatically via POST /workflows with a nodes-and-edges body if you prefer pipelines defined through REST. Run it once in the UI and inspect every node's output. This is the step that has no Replicate equivalent: you validate the entire chain visually before any code touches it.
Step 3: Swap the client code
Replace your per-model Replicate calls with a single execute call. Where Replicate needed one request per model plus polling for each, the canvas API needs one request for the whole graph:
curl -X POST https://www.wireflow.ai/api/v1/workflows/YOUR_WORKFLOW_ID/execute \
-H "Authorization: Bearer sk-your-api-key" \
-H "Content-Type: application/json" \
-d '{ "nodes": [...], "edges": [] }'
The response returns a 201 with an executionId. Authentication is a standard Bearer token, the same pattern Replicate uses, so the swap in most codebases is a URL and payload change rather than a rearchitecture.
Step 4: Port your polling loop
Replicate's prediction polling translates directly. Poll the execution until it leaves the RUNNING state:
curl https://www.wireflow.ai/api/v1/workflows/executions/exec_456/poll \
-H "Authorization: Bearer sk-your-api-key"
States are RUNNING, then COMPLETED with node outputs or FAILED with an error. Use exponential backoff starting at one second, multiplying by 1.5, capped at ten seconds between polls. If you were running an inference API with retry logic already, that code carries over with new field names.
Step 5: Move webhooks and background triggers
If you triggered Replicate predictions from forms, Zapier, or CI, the webhook endpoint replaces them without credentials on the trigger side. POST /workflow/{webhookId}/trigger starts a run and returns 202 with an executionId; no API key is required on that call, and CORS is open, so browser-side triggers work. You then poll with your key server-side. Details and payload shapes are in the webhook docs.
Step 6: Add idempotency and cut over
Replicate has no native idempotency, so most teams built deduplication themselves. Here you send an Idempotency-Key header on the execute call; identical keys within 24 hours replay the original response instead of running the pipeline twice. Once staging traffic runs clean, point production at the new endpoint and retire the Replicate calls one pipeline at a time, the same pattern headless workflow platforms recommend for any provider migration.
Concept mapping: Replicate to canvas API
| Replicate concept | Canvas API equivalent |
|---|---|
Model endpoint (owner/model) |
Model node (generate:flux_2, edit:flux_2_edit, etc.) |
replicate.run() per model |
One POST /workflows/{id}/execute for the whole graph |
| Prediction polling | GET /workflows/executions/{id}/poll |
| Glue code between calls | Edges on the canvas |
| Webhook on prediction complete | POST /workflow/{webhookId}/trigger pattern |
| Per-hardware-second billing | Per-execution credits with a 402 breakdown per node |
| Cog packaging for custom chains | Published workflow becomes a callable app |
The billing difference deserves a note: when credits are insufficient, the API returns a 402 that itemizes required credits per node, so cost surprises surface before execution rather than on the invoice, a contrast most canvas API platforms treat as a headline feature.
Plan for rate limits and cost
Request limits scale by plan (10 requests per minute on Free up to 200 on Enterprise), but execution starts are capped at 10 per minute on every tier, which prevents a runaway script from draining credits. Daily execution caps run from 50 on Free to 200 on Starter, 1,000 on Pro, and unlimited on Enterprise. Every response carries X-RateLimit-Remaining and X-RateLimit-Reset headers plus Retry-After on 429s, so your backoff logic has real data to work with; teams comparing usage-based API pricing generally find per-execution credits easier to budget than hardware-seconds because one execution maps to one user action.
Try it yourself: Build this workflow in Wireflow shows the migration target in miniature: a text input node feeding FLUX 2 Pro, already executed with real output. The nodes are pre-configured with the exact setup discussed above.
FAQ
Do I have to rewrite my whole codebase to migrate? No. The API surface is plain REST with Bearer auth, the same shape as Replicate's. Most migrations change the endpoint URL, the request payload, and the polling field names. The bigger change is deleting code: the glue between per-model calls goes away.
Can I chain image generation into video in a single API call? Yes. That is the core difference. The chain is defined as nodes and edges on the canvas, and one execute call runs the entire graph, image generation feeding video generation without your code touching the intermediate output.
What happens to my Replicate webhooks?
Replace them with webhook triggers. POST /workflow/{webhookId}/trigger needs no API key, returns 202 with an execution ID, and allows open CORS, so forms, Zapier, and CI triggers port over directly.
How do I avoid duplicate executions during the cutover?
Send an Idempotency-Key header on execute calls. Identical keys within 24 hours replay the original response instead of running the workflow again, which makes retry logic safe by default.
How does pricing compare to Replicate's per-second billing? Replicate bills for hardware time, so cost varies with cold starts and model load speed. Canvas API executions cost fixed credits per node, and a 402 response itemizes the per-node credit breakdown before anything runs, so budgeting happens up front.
Is there an official SDK? No, and none is needed. The API is plain REST plus JSON, so curl, fetch, axios, or Python requests all work. Code examples in the API workflow docs use curl and fetch.
What are the rate limits I should design around?
Requests per minute scale by plan (10 to 200), but execution starts are capped at 10 per minute on every tier. Design batch jobs to serialize execution starts and read the X-RateLimit-Remaining header rather than guessing.
Can AI agents like Claude drive these workflows? Yes. An official Claude Skill lets Claude Code and Claude Desktop create and execute workflows through the same API, which is useful if your Replicate calls were already being orchestrated by an agent.
Conclusion
Migrating from Replicate to a canvas API is less a rewrite than a consolidation: per-model endpoints collapse into one workflow endpoint, glue code becomes edges, and debugging moves from log statements to a visual graph. The sequence that works is inventory your calls, rebuild the chain as nodes, swap the execute and poll calls, port webhooks, then cut over with idempotency keys in place. Start with your simplest pipeline, confirm the output matches what Replicate produced, and move the rest one workflow at a time. The workflow linked above is a working two-node starting point you can fork and extend on Wireflow's canvas today.
