Build a Multimodal Workflow with Rivya API

A good Rivya API integration is not just one request to one model.

Most real product workflows have a small chain: choose the right model, prepare the input, upload reference files when needed, submit a job, watch status, handle credits, and notify the product when the result is ready.

This article shows the planning shape. Use Rivya API Quickstart for the shortest runnable path, and use the API docs for exact request fields.

Start With The Product Moment

Before choosing endpoints, describe the product moment in one sentence.

Examples:

• Create a product image draft when a seller submits a listing brief.

• Generate a short video concept after a campaign manager approves a still direction.

• Send a chat turn inside an internal research tool and stream the response back to the user.

• Upload a reference image, submit a supported model request, and notify the user when the result is ready.

That sentence prevents the integration from becoming a loose collection of API calls.

Map The Workflow Before Writing Code

Use this table before opening the request schema.

The workflow should be clear enough that each API area has a reason to exist.

Step 1: Create A Key For The Integration

Create an API key for the specific app, environment, or workflow that will use it.

Avoid using one key for everything. Naming keys by purpose makes later review easier:

• production-image-workflow

• staging-video-tests

• internal-chat-assistant

• webhook-smoke-test

Read API Authentication before storing the key. The full secret is shown once, so your team should save it in the right server-side secret store immediately.

Step 2: Choose Models From The Public API List

Do not hard-code a model just because it worked in a manual test.

Use API Models and Model API Reference to confirm:

• the public model ID

• whether it is available through the API

• supported input mode

• prompt and parameter expectations

• whether Files API is required

• credit behavior and readiness notes

This is where many integrations get cleaner. A model that is perfect for a manual Studio test may not be the right first model for an automated product flow.

Step 3: Decide Whether Files API Is Part Of The First Version

If the model can run from text input, keep the first version text-only.

Add Files API only when the workflow genuinely needs reference media.

When it does, define:

• which file kinds the product accepts

• who owns the file cleanup step

• what happens when upload fails

• how the returned file data is passed into model parameters

• whether the same file should be reused or uploaded again

This prevents a fragile file experience from being hidden behind a clean-looking generate button.

Step 4: Submit One Generation Job

For image, video, and audio generation, the normal pattern is:

1. prepare the model ID, prompt, and supported params

2. add an idempotency key for safe retries

3. submit through the generation endpoint

4. save the public task ID

5. poll status until the task reaches a terminal state

Use Create Generation for the request shape and Generation Status for result handling.

The product should treat queued, processing, succeeded, and failed as user-facing states. Do not make users read system details or guess why a job is slow.

Step 5: Use Chat API For Chat Models

Chat models should use Chat API, not the generation endpoint.

That matters because chat work has different behavior:

• chat turns can belong to API-created sessions

• non-streaming and SSE streaming have different user experiences

• image attachments use file IDs from Files API

• credit settlement follows the chat turn rather than a normal async media task

If your product needs an assistant answer inside its own interface, Chat API may be the right path. If the user is still exploring ideas, Rivya Chat or Studio may be better.

Step 6: Start With Polling, Then Add Webhooks

For a first version, polling is easier to reason about.

Add API Webhooks when:

• the product has many async jobs

• waiting clients should not poll directly

• downstream systems need signed completion events

• retry and duplicate handling are already designed

Webhook receivers should be boring and strict: verify the signature, accept duplicate-safe events, update one product record, and log only what is safe to log.

Step 7: Make Credits Visible In The Product

Rivya API uses the same account credits as Studio.

Your integration should decide how much of that to show. At minimum, the team should know:

• which account owns the API key

• which workflow can consume credits

• what happens when credits are too low

• how failed generation states are explained

• where to send someone for credit and billing questions

Use API Credits, Credits & Billing in Rivya, and How to Think About Rivya Credits, Packs, and Plans for the user-facing wallet model.

A Small First Version

A good first version is intentionally limited.

For example:

1. one API key

2. one selected image model

3. no file upload yet

4. one generation request

5. one status polling path

6. one simple result preview in your product

7. one clear credit error message

That version proves the connection before adding more moving parts.

A More Complete Version

After the first version works, a fuller workflow might add:

• Files API for reference images or videos

• model-specific parameter controls

• idempotency tied to your product record

• signed webhooks for completion

• Chat API for assistant turns

• a server-side event stream where chat needs live output

• admin or support views for failed jobs

Each addition should answer a real product need. If it only makes the demo look bigger, leave it out.

Common Integration Mistakes

Avoid these patterns:

• starting with every API feature at once

• hiding credit usage from the account owner

• using Studio-only assumptions in an API flow

• treating file uploads as an afterthought

• retrying generation requests without idempotency

• using Chat API for jobs that should be async generation

• using generation endpoints for chat turns

• logging full API keys, webhook secrets, or temporary file details

The safest API workflow is explicit about ownership, state, and failure handling.

Where To Go Next

• Start from Developers for the public API hub.

• Use Rivya API Quickstart to run the first request.

• Use API Models before selecting model IDs.

• Use Files API only when the model really needs reference media.

• Use Chat API for chat turns and streaming chat responses.

• Use API Webhooks when polling is no longer enough.

• If the workflow still needs human exploration, read When to Use Rivya API Instead of Studio before automating it.