If your catalog lives in a PIM, an ERP or a homegrown listing pipeline, the browser is the wrong interface. The CatalogX API (Business plan and above) exposes everything the app does: try-on including pose reference and saved poses, your saved custom models and backgrounds, fixes and enhancement, Leaflet catalog cards and brand kit, marketplace exports with AI-disclosure metadata written in. The public docs are maintained at feature parity with the app.
The headline policy: credits are the only ceiling
Requests authenticated with a valid API key are exempt from all rate limits and all concurrency caps. Want to burst 50 generations in parallel at 2 a.m. when your feed refreshes? That is what the policy is for. Two design details behind it:
- API traffic never starves your team. API requests don't consume the same in-flight slots as the web app, so a pipeline hammering the API doesn't lock your staff out of the studio.
- The exemption is for verified customers only. Forged or revoked keys fall back to strict IP-based limits, fail-closed.
Context from the market (verified September 2026)
FASHN's API caps concurrency at 6 — and is the only route to catalog scale they offer, since the product has no batch interface. Other APIs meter per call with their own rate tiers. "No rate limits; credits are the meter" is a deliberately simpler contract: capacity planning collapses into one question — how many credits does the month need?
What we deliberately don't claim
No SLA theatre: there's no dedicated-infrastructure tier or uptime contract, and the agent-chat endpoints are app internals rather than public API surface. What you get is the entire feature set, programmable, with predictable billing.