Tokenify

The Seedream API format

Code written against the Seedream API works here by changing the base URL and the key: the same fields, the same response, the same error codes.

What you change

The base URL and the key. The path is the one that format uses, so both spellings of the base URL work: set it to https://api.tokenify.dev and your client builds /api/v3/images/generations itself, or set it to https://api.tokenify.dev/api/v3 and it appends the rest.

curl https://api.tokenify.dev/api/v3/images/generations \
-H "Authorization: Bearer $TOKENIFY_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"model": "bytedance/seedream-5.0-pro",
"prompt": "A still life of three pears, soft window light",
"size": "2K"
}'

model takes our ids, and it also takes the model ids that format uses — so a request that names a model the way your existing code does keeps working. The reply echoes whichever you sent, which is what a client comparing the two expects.

Those ids work on this endpoint and nowhere else. On /v1/images/generations, on /v1/chat/completions and in /v1/models the only names are ours.

The fields

FieldHere
promptRequired, unless you send an image to work from.
imageOne string or an array. An https URL or a data URI. The per-model ceiling is in /v1/models as max_input_images.
sizeA tier or WIDTHxHEIGHT, per model. The tiers and the range are on the image generation page.
response_formaturl (the default here, as in that format) or b64_json. Our links last 7 days.
output_formatpng or jpeg.
backgroundtransparent or opaque, on the models that have it. Transparent needs png.
watermarkfalse by default here, which is the one default we changed. Send true to have the mark.
sequential_image_generationWith sequential_image_generation_options.max_images, asks for several images. The ceiling is per model. disabled together with a max_images above one is a 400: the two halves of that request disagree about how many images you are paying for, so neither reading of it is ours to pick.
layer_decompositionSplits one image into a base and its layers. See layer decomposition.

Accepted and ignored: optimize_prompt_options, seed, guidance_scale. Refused with a 400 naming the field: stream (not yet), and anything unrecognised.

The reply

{
"model": "bytedance/seedream-5.0-pro",
"created": 1760000000,
"data": [{ "url": "https://img.tokenify.dev/…", "size": "2048x2048", "output_format": "jpeg" }],
// Ours, not part of that format: Unix seconds, 7 days out.
"expires_at": 1760604800,
"usage": {
"generated_images": 1,
"input_images": 0,
// Their metering rule — the sum of width x height over the images in this
// reply, divided by 256. Not what you are charged on: the charge is per image.
"output_tokens": 16384,
"total_tokens": 16384
}
}

Where we differ

ThereHere
Link lifetime24 hours7 days, and the reply says when in expires_at
WatermarkOn by defaultOff by default; send watermark: true for it
StreamingSupported on some modelsA 400. The reply is one JSON document
Unknown fieldsIgnoredA 400 naming the field, so a parameter you expected to work cannot silently do nothing
ModelsSeveral generations of themThe three on our models page. A model id we do not serve is a 404 listing what we do.

Errors

The envelope and the codes are that format’s, so a client switching on error.code keeps working:

{ "error": { "code": "InvalidParameter", "message": "…" } }
CodeWhen
InvalidParameterA field is wrong: the size, an image, an unknown parameter.
MissingParameterNo prompt and no image, or no model.
InvalidEndpointOrModel.NotFoundA model we do not serve.
AccessDeniedThis key is not permitted to use that model.
AccountOverdueErrorYour balance will not cover the request.
SensitiveContentDetectedThe content policy refused the request.
ModelAccountIpmRateLimitExceededAbove your images a minute. Retry-After says when.
InternalServiceErrorOur side or the model’s. Nothing is charged.
The message is ours, not theirs. We never forward the upstream error text — it names the service that generated the image, and on these models it reports a rate limit for a request that simply could not be served.

Last updated 2026-10-12.