The Bijify API

Everything you can do on bijify.com, you can now do from your own code.

Upload a photograph of a piece of jewelry, choose how it should be presented, and receive a finished image or a short video. No model shoot, no studio booking, no retouching queue. The same HTTP generation API that we created to power our web app is available to your own code, and we have written the documentation we would have wanted ourselves. Bijify.com is its first-party client, so changes to the shared upload, generation and job contract are exercised by our own product.

Read the full API reference

What you can build with it

The API is deliberately not a black box with one button. It exposes the same building blocks our own interface uses:

• On-body imagery. Your ring, earrings, necklace or bracelet worn by an AI-generated model, with control over camera framing, age, skin tone, pose, wardrobe, lighting and scene. There are more than twenty categories of choices per mode.
• Still-life imagery. Studio product shots on styled surfaces, with the same depth of control.
• Video. A short cinematic clip generated from a single still photograph.
• A visual picker. Every preset has a thumbnail served from our CDN, so your interface can look like a catalog rather than a wall of dropdowns.
• Example templates. Our public inspiration gallery is queryable, and each entry carries the exact settings that produced it. You can let a customer click a look they like and reuse those settings verbatim.

A typical integration is four calls: upload the bytes, start a job, poll it, download the result. A single upload can feed as many generations as you like, so letting a shopper preview six different styles on one photograph costs one upload and six generations.

Getting an API key

API access is part of the Max plan. If you are on Max, you can create your key yourself, right now, at Dashboard → API Keys. No waiting on us.

Get the Max plan

You get one key per account, and you can disable, delete or recreate it whenever you like. The same screen shows how much it has been used and from where. The key itself is shown once, at creation. Store it somewhere safe, because we only keep a hash of it and cannot show it to you again.

A key looks like ak_ followed by 32 hexadecimal characters, and it goes in an Authorization: Bearer header on every request.

When you create a key you register its allowed browser domain. Cross-origin browser calls to api.bijify.com include a browser-controlled Origin header, so JavaScript running on another website cannot claim to be your domain. Backends and CLIs normally omit that header, and Bijify accepts API-key requests without it so server-to-server integrations work.

Keep your key on your server. It is a bearer credential with authority to spend your credits. The allowed browser domain blocks direct reuse from another website, but it does not make an exposed key safe: anyone can recover a key embedded in browser JavaScript and use it from a server or CLI without an Origin header.

Route requests through your own backend, authenticate your customers there, and apply whatever per-user, per-order or daily limits make sense for your store. Bijify attributes the traffic to your account and key; it does not identify or impose separate quotas on your individual customers.

How usage and charges work

Bijify runs on credits, and the API bills exactly like the web app does.

Each generation costs a fixed number of credits, depending on the workflow you pick. The /workflows endpoint reports the current price for each one, and you should read it at runtime rather than hardcoding it, because prices change as models improve. Today the range runs from 25 credits for a fast standard-definition image up to 300 for a 1080p video.

You only pay for work that succeeds. Your balance is checked when a job is accepted, and credits are charged only when that job completes. If a generation fails for any reason (a bad input, a model refusal, an infrastructure hiccup, or our 90-minute watchdog killing a stuck job) nothing is charged at all. A failure costs you nothing but time.

Uploading the same image twice is free. Uploads are content-addressed, so re-uploading identical bytes returns the same storage reference without consuming your daily upload allowance.

The allowances. Up to 50 MB per file, and 1 GB of newly uploaded bytes per account per day. Requests are rate-limited; if you receive a 429, back off and retry.

Running out of credits shows up as HTTP 402 when you try to start a job. Top up from the dashboard.

One honest limitation worth stating plainly: there is currently no endpoint that reports your credit balance, so you cannot pre-check affordability from code. You either track your own spend or read the balance from the dashboard. It is on our list.

Two things that will save you a day

The reference covers everything, but two details account for most of the confusion we have seen.

Results expire, and you must fetch them from your server. When a job completes you get a signed URL valid for two hours, minted once. Polling again returns the same, already-aging link. Download the bytes and re-host them as soon as the job finishes; the job record itself is deleted 24 hours later. Keep your own history and do not treat our job IDs as durable storage.

One detail that costs people an afternoon: those media URLs are origin-checked. Your backend can fetch them freely, and a plain <img src> or <video src> tag works fine, but a scripted fetch() from your own page will be refused. Download server-side.

Choices interact. Each mode ships a set of rules describing which categories stop applying given other choices. Picking earrings makes the ring-specific poses irrelevant, and the higher-quality workflows drop the enhancement controls they make redundant. The server applies these rules whether or not you do, so nothing breaks if you ignore them. But mirroring them in your interface is the difference between a picker that feels intelligent and one that offers controls which quietly do nothing. The reference gives you the complete algorithm as working code.

Start here

• The full API reference: every endpoint, every field, every limit, with worked examples.
• The reference as Markdown: the same document as a plain file, ready for your repository or your AI assistant.

If you are integrating and something in the documentation is unclear, wrong, or missing, tell us at [email protected]. We would rather fix the document than answer the same question twice.