For AI agents: this page is also available as Markdown at https://docs.refabric.com/why-refabric.md, and the index of every page is https://docs.refabric.com/llms.txt.
Why Refabric
What you get from one API built for fashion work.
Refabric's tasks are the steps of a fashion workflow — design, edit, shoot, animate, prepare for production — and each one takes and returns the things that workflow uses: garments, products, fabrics, moodboards, models and poses. This page lists what that means for your integration, and where each point is documented.
One API for the fashion workflow. Every task is called the same way: POST /v1/tasks/{name}
with its input, a job, a result. The categories and tasks are the live catalogue
(Task API Reference); a task added to it is called like every other one.
Garment-faithful edits. An edit task changes one thing and states what it keeps. For example,
image.change_background replaces the backdrop and keeps the person, the garment and the styling;
image.repose changes the pose and keeps the person and the clothes. Each task's page says what
it keeps and what it changes (Task API Reference).
Records, not just images. A moodboard, a fabric, a brand kit or a range plan comes back as a
record with an id (moodboard:…), structured data and a preview image. You pass the id to the
next task instead of re-sending pictures (Records & libraries).
Maximum cost before you run. POST /v1/tasks/{name}/estimate takes the same body as a run and
answers the most that request can cost. Submitting holds that amount; only what is delivered is
charged, and the rest of the hold comes back when the job ends (Pricing).
One error shape everywhere. A refused request, a failed job, a webhook for a failed job and a
Prefer: wait answer all carry the same error object, with a stable code, a field and a
retryable flag (Task errors).