GETMethod GET/partner/mint/batch/status/{job_id}

You follow the progress of a batch sent for minting, and you know when to stop your loop. Poll this endpoint as many times as needed: it neither creates nor modifies any product, and it consumes no daily quota. Read the warning below before concluding, from this read, that your items exist.

The server exposes two addresses that call the same code: /v1/partner/mint/batch/status/{job_id} and /partner/mint/batch/status/{job_id}. Use the /v1 form for any new integration.

#Authorization

Scope required on the key: mint:batch.

It is the same scope as the submission of a batch. A key that does not have that scope receives 403, and the message names the missing scope.

Authenticate through the Authorization header, in the Bearer format.

Authorization: Bearer votre_clef

Only a key of the brand that submitted the batch can read it.

#Rate limit

The rate limit of the partner API applies to this endpoint, over a fixed window of 60 seconds.

Two counters run at the same time, one for your key, one for the sum of the keys of your brand. The limit applied comes from a value set on your account, or failing that from your plan. When neither of the two is defined, it is 120 calls per window.

Do not guess that value. Every response that has cleared the rate check carries four headers that give it. A 401 response, an authentication 403 or a 503 arrive before or during that check, and do not carry them.

This endpoint consumes no unit of your daily quota, and no unit of the monthly product quota of your plan.

#Path and query parameters

This endpoint accepts no query parameter.

#Request body

None. This is a read, it has no body.

#Example request

curl -sS https://api.sealtrust.io/v1/partner/mint/batch/status/0000a1b2c3d4e5f6 \
  -H "Authorization: Bearer st_test_0000000000000000000000000000000000000000000000"

import { SealTrustClient } from "@sealtrust-io/sdk";

const sealtrust = new SealTrustClient({
  apiKey: "st_test_0000000000000000000000000000000000000000000000",
});

const etat = await sealtrust.products.getBatchStatus("0000a1b2c3d4e5f6");

console.log(etat.status);
console.log(etat.is_finished);

import requests

response = requests.get(
    "https://api.sealtrust.io/v1/partner/mint/batch/status/0000a1b2c3d4e5f6",
    headers={
        "Authorization": "Bearer st_test_0000000000000000000000000000000000000000000000"
    },
    timeout=30,
)

print(response.status_code)
print(response.json()["status"])

#Example response

HTTP status code 200, for a batch of 500 rows being processed, twelve rows of which have already succeeded.

{
  "job_id": "0000a1b2c3d4e5f6",
  "status": "started",
  "is_finished": false,
  "batch_status": "pending",
  "items_count": 500,
  "success_count": 12,
  "error_count": 0,
  "enqueued_at": "2026-08-20T09:14:32.118431+00:00",
  "started_at": "2026-08-20T09:14:33.402118+00:00",
  "ended_at": null,
  "result": null,
  "exc_info": null
}

The twelve keys are always present in this shape of response. Only their values change. The counters are there from your first call: each row of the batch is counted at the moment it succeeds. When the processing of the batch reaches its end, is_finished turns true and ended_at carries a date. That tells you that the processing went all the way through. To know how many items were created, read success_count.

The three dates carry the +00:00 offset: they follow universal time.

The response carries two more fields, result and exc_info. They are internal to our processing. Ignore them: do not display them, do not store them, do not wire any logic to them. Neither of the two tells you how many items were created.

#The values of status

Values other than these five can appear. The types of the TypeScript SDK declare four more: deferred, scheduled, stopped and canceled. Write your loop so that it handles an unexpected value without crashing.

Loop as long as the status is queued or started. Stop on finished, on failed and on unknown. Stopping your loop tells you nothing about the number of items created: that number is read in success_count.

#The values of batch_status

A batch submitted through this API starts at pending. Only its processing makes it change, to retrying, to pending_multisig, or to a terminal state, success, partial or failed. The running value does not appear on this path: do not write a branch for it. partial means that only part of the items were created. Compare success_count and items_count in that case.

#The response when no reachable batch matches

When no batch reachable with your key matches the identifier, you receive 200, with two fields and nothing else.

{
  "job_id": "0000a1b2c3d4e5f6",
  "status": "unknown"
}

#The second shape of response, on an old batch

We only keep the detail of how the processing went for a time. Past that delay, the response takes a second shape, built from the state of the batch itself. It carries the first seven fields and nothing else: neither the three dates, nor the two internal fields. The counters, for their part, are in both shapes. Handle both shapes.

{
  "job_id": "0000a1b2c3d4e5f6",
  "status": "failed",
  "is_finished": true,
  "batch_status": "failed",
  "items_count": 500,
  "success_count": 0,
  "error_count": 500
}

It can carry any status, including queued and started. Do not deduce from its shape that the batch is over.

In this shape of response, is_finished is true for success, partial and failed, and status comes from the state of the batch. A batch every row of which was rejected answers status: "failed" and is_finished: true here, and the first shape answers the same thing for the same run. Do not compare two reads made at different moments to deduce that the batch has changed state. The number of items created is read in success_count.

#Errors

No error code in this list depends on the content of the batch. The check for the refusals tied to the batch itself, size, columns, categories and the quota of your plan, takes place at the moment of the submission, on POST /v1/partner/mint/batch.

#See also

• POST /partner/mint/batch, submit a batch of product rows, up to 500 per call.
• Create products, one at a time and in batches, create a product, create a whole run, import a file.
• API errors, recognize an error code and decide whether to fix or replay.
• Integrate the TypeScript SDK, install the SDK, create the client and recognize the two families of errors.