Reviral API Changelog — September 2026

September's API release adds a categorized documentation site, a dedicated reference page for every one of the 58 live models, a public status page at /api-status, and search-engine indexing support. Every request still charges the exact price shown in GET /api/v1/models, and every render can now lock that price with maxCredits before it fires.

This is a documentation and discoverability release, not a breaking one. Nothing about how POST /api/v1/generate-media or GET /api/v1/jobs/{id} works changed — what changed is how easy it is to find the exact page for the model you want to call, and how much of that page is now sourced live from the catalog instead of written by hand and left to go stale.

Categorized documentation

The API documentation is now organized into sections instead of one long page: Get started (quickstart, authentication, credits and pricing, rate limits, idempotency), Endpoints (one page per route — models, generate-media, render, jobs, calculate-credits, credit-costs, me, characters, media-search), Models (split into Video and Image), Webhooks, Errors, Changelog, and FAQ. Every endpoint page reads its request schema, required fields, and response codes directly from the checked-in OpenAPI file at build time — the same file this whole release is built to keep as the single source of truth, so the documented shape of a request and the shape the server actually accepts cannot drift apart silently.

A page for every one of the 58 models

Every model in the live catalog — 40 video, 18 image, across 15 model families — now has its own page under /docs/api/models: exact duration range or fixed durations, every supported resolution and aspect ratio, and the current credit price computed the same way the render route computes it, not a cached or rounded estimate. Search or browse from the model index, or go straight to a specific one — /docs/api/models/seedance-2, /docs/api/models/veo-3.1-quality-flat, /docs/api/models/nano-banana-pro, and so on for the rest of the catalog.

This matters for the same reason reading GET /api/v1/models before you render matters: a model's accepted settings and price are facts about the live catalog, not facts that belong in a blog post or a hardcoded table. These pages are generated from that catalog on every rebuild, so a price change or a newly added model shows up on its page without anyone hand-editing documentation.

The price-lock explanation, in the quickstart

The quickstart and credits and pricing pages now walk through maxCredits explicitly, since it is the one field most likely to matter to anyone calling the API from a billing-sensitive pipeline. Set it to the credit price you just read from the catalog:

{
  "model": "seedance-2",
  "prompt": "...",
  "durationSec": 5,
  "resolution": "720p",
  "aspectRatio": "16:9",
  "maxCredits": 106
}

If the live charge is still exactly 106 credits when the request is processed, the job starts normally. If the price has moved by then — a model's cost changing between your catalog read and your render call — the request fails with 409 price_changed instead of silently charging a different number than the one you approved. Leave the field out and the job runs at whatever the live price is at request time; set it and you get a hard ceiling on the charge. That distinction is now spelled out on the docs instead of left for someone to infer from the field's one-line schema description.

A public status page

reviral.ai/api-status now exists as a standing page, not just a support answer. It publishes live per-model availability and current pricing pulled from the same catalog every other doc page reads from, so a 502 or 503 from generate-media or jobs can be checked against a real page before anyone assumes their own integration broke. The errors reference now points here directly, and it also links an operational-notices channel — a lower-friction way to hear about a temporary disruption than refreshing a status page on a timer.

Search-engine indexing for the new pages

All of the pages above are now included in the sitemap, and this release adds support for IndexNow — a shared protocol that lets a site tell participating search engines about a new or changed URL directly instead of waiting for the next scheduled crawl. The mechanics: a key is published at a stable URL only the site itself controls, and a participating engine can fetch that URL to confirm the submission is legitimate before trusting it. That verification endpoint is live now; a batch submission of the new documentation URLs is a separate, deliberate step and is not something this changelog claims already happened.

Compatibility

Nothing in this release removes or renames an existing field, endpoint, or response shape. New optional fields, new models, and new enum values can be added within the current API version without warning — the documented compatibility policy is unchanged: clients should ignore unknown response fields and read the current catalog before validating a model choice, rather than hardcoding a list that this same release just made easier to keep current automatically.

Where to read the raw entries

This post is the narrative version. The in-docs changelog keeps the terse, dated entry list this release started: generated endpoint and per-model documentation added, model defaults added to the public catalog contract, and the checked-in OpenAPI file made the single machine-readable source for both the docs site and the /openapi.json route itself. Check that page for future entries — this post covers the September release; the docs page is where the next one gets logged first.

Questions about this release

Did any request or response field change?

No. This release is documentation, discoverability, and status infrastructure. The request and response shapes for every endpoint are unchanged; the OpenAPI file simply became the one place both the server and the docs read that shape from.

Do I need to update anything in my integration?

No action is required. If you were reading model prices from a hardcoded table instead of GET /api/v1/models, this is a good moment to switch — the per-model docs pages are generated from that same live endpoint, so the two will never disagree.

Is the status page the same as an uptime guarantee?

No — it is a live read of current model availability and pricing, useful for distinguishing a temporary upstream issue from a problem in your own code before you escalate. It is not a formal SLA page.