Submit up to 100 jobs together
One default request plus items that override parts of it, merged one level deep: an item's field wins, everything else comes from the default. The default is written for the batch's kind, so it applies only to items of that kind; an item that names a different kind stands on its own request, and any item may carry its own delivery. Every item is validated as a single job would be, and an unknown field is refused rather than ignored, because a typo that is silently dropped is a render spent on the wrong thing.
The batch is accepted or refused whole. Every item is validated before any is stored, and every item is admitted on your billing account in one step, so a batch any item of which cannot be admitted is refused with the billing code, reserves nothing and leaves no jobs behind. Each item then commits or releases on its own as its job finishes. A validation error names the item that was wrong. A batch that would take the account past 1,000 unfinished jobs is refused whole the same way, with 429 queue_full.
Items are ordinary jobs: poll them individually, or poll the batch for the aggregate. There is no ZIP of results - configure a storage destination if you want the output collected in one place.
Send Idempotency-Key to make the submission safe to retry: the same key returns the batch it first created, with its jobs and another 202, instead of a second set of jobs and a second reservation. The request is not compared with the first. Poll the batch for its current counts.
Request
- Base URL: https://api.ironfang.com/render
- URL: https://api.ironfang.com/render/v1/batches
- Auth: HTTP bearer
Headers
Makes a submission safe to retry. Any string up to 255 characters; surrounding whitespace is ignored and a longer key is a 400 bad_request. A key is remembered per account for as long as the job it created exists, and has no expiry of its own. Jobs and batches keep separate key spaces.
A job submitted again under its key returns the existing job with 200 when the request is the same, and is a 409 idempotency_conflict when it differs. A batch submitted again under its key returns the batch the key first created, with its jobs and 202; the request is not compared, so a batch has no conflict response.
Request body
Example request
{
"delivery": {
"storage_key": "captures/{external_id}/{job_id}.png"
},
"items": [
{
"delivery": {
"storage_key": "captures/{external_id}/{job_id}.png"
}
}
]
}Response
The batch was accepted; the body carries the batch and one job per item.
Changes
No recorded changes to this operation across all 1 revision of this API.