Move to VizoAPI from another provider

Each tab below has a prompt for your coding agent (Claude Code, Codex, Cursor or similar). Paste it into the agent in your project. The prompt tells the agent how to map your current provider's authentication, task creation, status checks or webhooks, and result fields onto VizoAPI.

Three differences matter in every migration. VizoAPI is asynchronous: creating a task returns at once and you collect the result later. A repeated create call is a second task and a second charge, so a timeout must not trigger a blind retry. Prices are in credits, and outputs are kept for 7 days.

The prompts describe the other provider only in general terms, and tell the agent to read that provider's current documentation. Check the diff and run one small task before you move traffic.

You are migrating this codebase from Replicate to VizoAPI. Change only the code that calls Replicate. Leave the rest of the application as it is.

Step 1. Find every place the code uses Replicate: client set-up, model calls, status checks, webhook handlers, and the code that reads the result. List them for me before you edit anything.

Step 2. Authentication. Replicate sends its API token as a bearer token in the Authorization header. Replace it with a header Authorization: Bearer <key>. Read the key from the environment variable VIZO_API_KEY. Keep the key on the server; never put it in browser or app code.
The base URL of every call below is:
https://api.vizoapi.com


Step 3. Models. Call `GET /v1/models` and choose the VizoAPI model and `operation` that matches the Replicate model used today. `GET /v1/models/{id}` returns the input schema of one model. If no match is clear, stop and ask me. Do not guess.

Step 4. Create the task. Replace the create call with `POST /v1/generations`. The body has `model`, `operation` and `input`. Put the prompt in `input.prompt`, the length in `input.duration_seconds`, the size in `input.resolution` and `input.aspect_ratio`, and the sound option in `input.generate_audio`. An input image is `input.asset_id` (step 6). Use `input.native` only for fields that the schema from step 3 lists. Add `metadata` with a `client_reference` of your own, such as your order id. The call returns HTTP 202 and the new task in the response body; keep its `id`. There is no synchronous result, so the code must wait for the task as in step 5. Do not retry a create call after a timeout: a second call creates a second task and a second charge. First look for the task with `GET /v1/generations` and the same `client_reference`.

Step 5. Wait for the result. Replicate code usually creates a prediction and then polls it until it reaches a final state, or waits with a helper that does this for you. Find that loop. If the code uses a helper that blocks until the output is ready, replace it with your own submit-and-poll function. Replace it with `GET /v1/generations/{id}`, called every 3 seconds and slowing to every 10 seconds. The task is finished when `closed_at` is not null. If `status` is "succeeded", take `result.asset_id`; when a task has several outputs, take every `asset_id` in `result.outputs`, in order. Call `GET /v1/assets/{id}/download` with each asset id and fetch the returned `url` at once, because it expires at `url_expires_at`. Fetch the `url` without the API key. Copy the file to your own storage, because outputs are kept for 7 days only. If the task finished without success, nothing can be downloaded: read `error.code` and handle it.

Step 6. Input files. If the code sends an image, video or audio file, upload it first: `POST /v1/assets/uploads` with `mime` and `max_bytes`, then PUT the bytes to the returned `upload_url`, then `POST /v1/assets/{id}/complete`. Pass the `asset_id` in the input. If the code only passes a public URL, check the model schema from step 3 for how to send it.

Step 7. Webhooks. If the code receives Replicate webhooks, replace that handler (the verification and the payload parsing) with the VizoAPI handler described below. With VizoAPI you pass `webhook_endpoint_id` when you create the task; create the endpoint in the console first. A delivery is a POST with the headers X-Relay-Event-ID, X-Relay-Timestamp and X-Relay-Signature. Select the signing secret by the X-Relay-Key-ID header, because each webhook key has its own secret and a single stored secret breaks when a key is rotated. Then verify Base64(HMAC-SHA256(signing secret, timestamp + "." + event id + "." + raw body)) with a constant-time comparison, accept timestamps within 5 minutes, and ignore an event id you have seen. The body has `task_id`, `type` and `event_id`. The `type` is one of `generation.succeeded`, `generation.failed`, `generation.canceled`, `generation.unresolved`, `generation.refunded` or `generation.late_result_available`. After verifying, call `GET /v1/generations/{id}` with the `task_id` and act on that read. If you do not use webhooks, delete nothing and add nothing here.

Step 8. Cost. VizoAPI prices are in credits. Read the charge from `price.charged` on the task and the balance from `GET /v1/wallet`. A task that cannot be funded fails with an `error.code` such as insufficient_balance. Do not copy Replicate prices into the code.

Step 9. Do not guess names. This prompt describes only the general Replicate pattern. Read the current Replicate documentation for its exact endpoint and field names before you change code that depends on them. Tell me every Replicate feature that has no VizoAPI equivalent instead of inventing one.

Step 10. Test. Run one small task end to end with the new code, and show me the diff and the result. Do not switch production traffic.

You are migrating this codebase from fal.ai to VizoAPI. Change only the code that calls fal.ai. Leave the rest of the application as it is.

Step 1. Find every place the code uses fal.ai: client set-up, model calls, status checks, webhook handlers, and the code that reads the result. List them for me before you edit anything.

Step 2. Authentication. fal.ai sends its key with the Key scheme in the Authorization header, not Bearer. Replace it with a header Authorization: Bearer <key>. Read the key from the environment variable VIZO_API_KEY. Keep the key on the server; never put it in browser or app code.
The base URL of every call below is:
https://api.vizoapi.com


Step 3. Models. Call `GET /v1/models` and choose the VizoAPI model and `operation` that matches the fal.ai model used today. `GET /v1/models/{id}` returns the input schema of one model. If no match is clear, stop and ask me. Do not guess.

Step 4. Create the task. Replace the create call with `POST /v1/generations`. The body has `model`, `operation` and `input`. Put the prompt in `input.prompt`, the length in `input.duration_seconds`, the size in `input.resolution` and `input.aspect_ratio`, and the sound option in `input.generate_audio`. An input image is `input.asset_id` (step 6). Use `input.native` only for fields that the schema from step 3 lists. Add `metadata` with a `client_reference` of your own, such as your order id. The call returns HTTP 202 and the new task in the response body; keep its `id`. There is no synchronous result, so the code must wait for the task as in step 5. Do not retry a create call after a timeout: a second call creates a second task and a second charge. First look for the task with `GET /v1/generations` and the same `client_reference`.

Step 5. Wait for the result. fal.ai code usually submits to the queue and then waits, either with the client library helper that subscribes to the request or with its own status loop. Find that code. Replace the helper with your own submit-and-poll function. The VizoAPI call does not stream progress logs. Replace it with `GET /v1/generations/{id}`, called every 3 seconds and slowing to every 10 seconds. The task is finished when `closed_at` is not null. If `status` is "succeeded", take `result.asset_id`; when a task has several outputs, take every `asset_id` in `result.outputs`, in order. Call `GET /v1/assets/{id}/download` with each asset id and fetch the returned `url` at once, because it expires at `url_expires_at`. Fetch the `url` without the API key. Copy the file to your own storage, because outputs are kept for 7 days only. If the task finished without success, nothing can be downloaded: read `error.code` and handle it.

Step 6. Input files. If the code sends an image, video or audio file, upload it first: `POST /v1/assets/uploads` with `mime` and `max_bytes`, then PUT the bytes to the returned `upload_url`, then `POST /v1/assets/{id}/complete`. Pass the `asset_id` in the input. If the code only passes a public URL, check the model schema from step 3 for how to send it.

Step 7. Webhooks. If the code gives fal.ai a webhook URL, replace that handler (the verification and the payload parsing) with the VizoAPI handler described below. With VizoAPI you pass `webhook_endpoint_id` when you create the task; create the endpoint in the console first. A delivery is a POST with the headers X-Relay-Event-ID, X-Relay-Timestamp and X-Relay-Signature. Select the signing secret by the X-Relay-Key-ID header, because each webhook key has its own secret and a single stored secret breaks when a key is rotated. Then verify Base64(HMAC-SHA256(signing secret, timestamp + "." + event id + "." + raw body)) with a constant-time comparison, accept timestamps within 5 minutes, and ignore an event id you have seen. The body has `task_id`, `type` and `event_id`. The `type` is one of `generation.succeeded`, `generation.failed`, `generation.canceled`, `generation.unresolved`, `generation.refunded` or `generation.late_result_available`. After verifying, call `GET /v1/generations/{id}` with the `task_id` and act on that read. If you do not use webhooks, delete nothing and add nothing here.

Step 8. Cost. VizoAPI prices are in credits. Read the charge from `price.charged` on the task and the balance from `GET /v1/wallet`. A task that cannot be funded fails with an `error.code` such as insufficient_balance. Do not copy fal.ai prices into the code.

Step 9. Do not guess names. This prompt describes only the general fal.ai pattern. Read the current fal.ai documentation for its exact endpoint and field names before you change code that depends on them. Tell me every fal.ai feature that has no VizoAPI equivalent instead of inventing one.

Step 10. Test. Run one small task end to end with the new code, and show me the diff and the result. Do not switch production traffic.

You are migrating this codebase from WaveSpeed to VizoAPI. Change only the code that calls WaveSpeed. Leave the rest of the application as it is.

Step 1. Find every place the code uses WaveSpeed: client set-up, model calls, status checks, webhook handlers, and the code that reads the result. List them for me before you edit anything.

Step 2. Authentication. WaveSpeed sends its API key as a bearer token in the Authorization header. Replace it with a header Authorization: Bearer <key>. Read the key from the environment variable VIZO_API_KEY. Keep the key on the server; never put it in browser or app code.
The base URL of every call below is:
https://api.vizoapi.com


Step 3. Models. Call `GET /v1/models` and choose the VizoAPI model and `operation` that matches the WaveSpeed model used today. `GET /v1/models/{id}` returns the input schema of one model. If no match is clear, stop and ask me. Do not guess.

Step 4. Create the task. Replace the create call with `POST /v1/generations`. The body has `model`, `operation` and `input`. Put the prompt in `input.prompt`, the length in `input.duration_seconds`, the size in `input.resolution` and `input.aspect_ratio`, and the sound option in `input.generate_audio`. An input image is `input.asset_id` (step 6). Use `input.native` only for fields that the schema from step 3 lists. Add `metadata` with a `client_reference` of your own, such as your order id. The call returns HTTP 202 and the new task in the response body; keep its `id`. There is no synchronous result, so the code must wait for the task as in step 5. Do not retry a create call after a timeout: a second call creates a second task and a second charge. First look for the task with `GET /v1/generations` and the same `client_reference`.

Step 5. Wait for the result. WaveSpeed code submits a task for a model and then polls the result of that task until it finishes, or uses its webhook option. Find that loop, including any synchronous mode that waits for the output. Replace it with `GET /v1/generations/{id}`, called every 3 seconds and slowing to every 10 seconds. The task is finished when `closed_at` is not null. If `status` is "succeeded", take `result.asset_id`; when a task has several outputs, take every `asset_id` in `result.outputs`, in order. Call `GET /v1/assets/{id}/download` with each asset id and fetch the returned `url` at once, because it expires at `url_expires_at`. Fetch the `url` without the API key. Copy the file to your own storage, because outputs are kept for 7 days only. If the task finished without success, nothing can be downloaded: read `error.code` and handle it.

Step 6. Input files. If the code sends an image, video or audio file, upload it first: `POST /v1/assets/uploads` with `mime` and `max_bytes`, then PUT the bytes to the returned `upload_url`, then `POST /v1/assets/{id}/complete`. Pass the `asset_id` in the input. If the code only passes a public URL, check the model schema from step 3 for how to send it.

Step 7. Webhooks. If the code gives WaveSpeed a webhook URL, replace that handler (the verification and the payload parsing) with the VizoAPI handler described below. With VizoAPI you pass `webhook_endpoint_id` when you create the task; create the endpoint in the console first. A delivery is a POST with the headers X-Relay-Event-ID, X-Relay-Timestamp and X-Relay-Signature. Select the signing secret by the X-Relay-Key-ID header, because each webhook key has its own secret and a single stored secret breaks when a key is rotated. Then verify Base64(HMAC-SHA256(signing secret, timestamp + "." + event id + "." + raw body)) with a constant-time comparison, accept timestamps within 5 minutes, and ignore an event id you have seen. The body has `task_id`, `type` and `event_id`. The `type` is one of `generation.succeeded`, `generation.failed`, `generation.canceled`, `generation.unresolved`, `generation.refunded` or `generation.late_result_available`. After verifying, call `GET /v1/generations/{id}` with the `task_id` and act on that read. If you do not use webhooks, delete nothing and add nothing here.

Step 8. Cost. VizoAPI prices are in credits. Read the charge from `price.charged` on the task and the balance from `GET /v1/wallet`. A task that cannot be funded fails with an `error.code` such as insufficient_balance. Do not copy WaveSpeed prices into the code.

Step 9. Do not guess names. This prompt describes only the general WaveSpeed pattern. Read the current WaveSpeed documentation for its exact endpoint and field names before you change code that depends on them. Tell me every WaveSpeed feature that has no VizoAPI equivalent instead of inventing one.

Step 10. Test. Run one small task end to end with the new code, and show me the diff and the result. Do not switch production traffic.

You are migrating this codebase from kie.ai to VizoAPI. Change only the code that calls kie.ai. Leave the rest of the application as it is.

Step 1. Find every place the code uses kie.ai: client set-up, model calls, status checks, webhook handlers, and the code that reads the result. List them for me before you edit anything.

Step 2. Authentication. kie.ai sends its API key as a bearer token in the Authorization header. Replace it with a header Authorization: Bearer <key>. Read the key from the environment variable VIZO_API_KEY. Keep the key on the server; never put it in browser or app code.
The base URL of every call below is:
https://api.vizoapi.com


Step 3. Models. Call `GET /v1/models` and choose the VizoAPI model and `operation` that matches the kie.ai model used today. `GET /v1/models/{id}` returns the input schema of one model. If no match is clear, stop and ask me. Do not guess.

Step 4. Create the task. Replace the create call with `POST /v1/generations`. The body has `model`, `operation` and `input`. Put the prompt in `input.prompt`, the length in `input.duration_seconds`, the size in `input.resolution` and `input.aspect_ratio`, and the sound option in `input.generate_audio`. An input image is `input.asset_id` (step 6). Use `input.native` only for fields that the schema from step 3 lists. Add `metadata` with a `client_reference` of your own, such as your order id. The call returns HTTP 202 and the new task in the response body; keep its `id`. There is no synchronous result, so the code must wait for the task as in step 5. Do not retry a create call after a timeout: a second call creates a second task and a second charge. First look for the task with `GET /v1/generations` and the same `client_reference`.

Step 5. Wait for the result. kie.ai code creates a task and then polls the task details until it finishes, or provides a callback URL. Find that loop and the callback handler. Replace it with `GET /v1/generations/{id}`, called every 3 seconds and slowing to every 10 seconds. The task is finished when `closed_at` is not null. If `status` is "succeeded", take `result.asset_id`; when a task has several outputs, take every `asset_id` in `result.outputs`, in order. Call `GET /v1/assets/{id}/download` with each asset id and fetch the returned `url` at once, because it expires at `url_expires_at`. Fetch the `url` without the API key. Copy the file to your own storage, because outputs are kept for 7 days only. If the task finished without success, nothing can be downloaded: read `error.code` and handle it.

Step 6. Input files. If the code sends an image, video or audio file, upload it first: `POST /v1/assets/uploads` with `mime` and `max_bytes`, then PUT the bytes to the returned `upload_url`, then `POST /v1/assets/{id}/complete`. Pass the `asset_id` in the input. If the code only passes a public URL, check the model schema from step 3 for how to send it.

Step 7. Webhooks. If the code gives kie.ai a callback URL, replace that handler (the verification, if any, and the payload parsing) with the VizoAPI handler described below. With VizoAPI you pass `webhook_endpoint_id` when you create the task; create the endpoint in the console first. A delivery is a POST with the headers X-Relay-Event-ID, X-Relay-Timestamp and X-Relay-Signature. Select the signing secret by the X-Relay-Key-ID header, because each webhook key has its own secret and a single stored secret breaks when a key is rotated. Then verify Base64(HMAC-SHA256(signing secret, timestamp + "." + event id + "." + raw body)) with a constant-time comparison, accept timestamps within 5 minutes, and ignore an event id you have seen. The body has `task_id`, `type` and `event_id`. The `type` is one of `generation.succeeded`, `generation.failed`, `generation.canceled`, `generation.unresolved`, `generation.refunded` or `generation.late_result_available`. After verifying, call `GET /v1/generations/{id}` with the `task_id` and act on that read. If you do not use webhooks, delete nothing and add nothing here.

Step 8. Cost. VizoAPI prices are in credits. Read the charge from `price.charged` on the task and the balance from `GET /v1/wallet`. A task that cannot be funded fails with an `error.code` such as insufficient_balance. Do not copy kie.ai prices into the code.

Step 9. Do not guess names. This prompt describes only the general kie.ai pattern. Read the current kie.ai documentation for its exact endpoint and field names before you change code that depends on them. Tell me every kie.ai feature that has no VizoAPI equivalent instead of inventing one.

Step 10. Test. Run one small task end to end with the new code, and show me the diff and the result. Do not switch production traffic.