The OpenRouter for virtual try-on

Same OpenAI-compatible chat completions habit you already know — specialized for person + garment try-on, with dedicated engines and a unified credit balance.

Short answer: OpenRouter is excellent for general LLMs and image models. TryOn-API.com uses the same OpenAI-compatible shape, but adds try-on-specific pieces: tryon_role tagging, a native multipart /tryon endpoint, dedicated try-on engines (e.g. Kling Kolors), and unified credits across try-on providers.

What “OpenRouter-style” means here

What OpenRouter does not specialize in

OpenRouter routes general LLM and image-generation models. It does not expose dedicated virtual try-on engines or a person/garment request shape. If your product is try-on, you want those primitives built into the gateway — not bolted on per provider.

Drop-in migration

# Three-line migration from an OpenAI / OpenRouter client
const client = new OpenAI({{
  baseURL: "https://tryon-api.com/api/v1",
  apiKey:  process.env.TRYON_API_KEY,
}});
// then set model to a try-on slug, e.g. kling/kolors-v1-5

Full side-by-side: TryOn-API.com vs OpenRouter vs direct SDKs. Docs: docs.html.

Frequently asked questions

Is TryOn-API.com a fork of OpenRouter?

No. It is an independent OpenAI-compatible gateway focused on virtual try-on. The “OpenRouter for try-on” phrase describes the product shape: one schema, many models, unified credits — specialized for person + garment workflows.

Do existing OpenAI SDKs work?

Yes. Point baseURL at https://tryon-api.com/api/v1, use your tryon_ key, and pass a TryOn-API model slug. Streaming via SSE and modalities:["image"] follow the familiar schema.

Can I fall back if Kling is slow?

Yes. Pass a models[] fallback chain and routing preferences (sort: price or latency, allow_fallbacks). The gateway routes to the next capable model when the primary fails.


See also the machine-readable llms.txt and full API reference.