> ## Documentation Index
> Fetch the complete documentation index at: https://docs.sutro.sh/llms.txt
> Use this file to discover all available pages before exploring further.

# Recover a Batch submission

> Check ingestion or recover an accepted job after an uncertain submission response.

Use this read-only endpoint after an
[idempotent Batch submission](/reference/api/running-batch-inference#retry-safe-s3-submission).
The key is scoped to the authenticated owner and deployment. Reading its state
never submits inference.

**idempotency\_key** `string` *required*

The submission's UUID, written in canonical lowercase form.

**Authorization** `string` *required*

Deployment API key in the form `Key YOUR_SUTRO_API_KEY`.

```bash theme={null}
curl --fail-with-body \
  "${SUTRO_API_URL%/}/v1/batch-submissions/889b580e-90ee-4c47-9949-1ae63c6dcb76" \
  -H "Authorization: Key $SUTRO_API_KEY"
```

## States

A known reservation returns HTTP `200`. Inspect `status` and `retryable` even
when the HTTP request succeeded.

| State | Meaning | Next step |
| - | - | - |
| `INGESTING`, `retryable: false` | The deployment is retaining and validating input. | Keep polling this key. |
| `INGESTING`, `retryable: true` | The ingestion lease expired. | Replay the original submission with the same key and pinned object. |
| `RETRYABLE`, `retryable: true` | A transient ingestion failure occurred. | Replay with the same key; refresh the signed GET URL if necessary. |
| `FAILED`, `retryable: false` | Input retention or validation failed terminally. | Inspect `code` and available `detail`, correct the problem, and intentionally use a new key. |
| `ACCEPTED` | The original job was created. | Monitor `results` as the job ID; do not submit another job. |

```json theme={null}
{
  "status": "ACCEPTED",
  "idempotency_key": "889b580e-90ee-4c47-9949-1ae63c6dcb76",
  "results": "job-12345678-1234-1234-1234-1234567890ab",
  "metadata": {
    "job_id": "job-12345678-1234-1234-1234-1234567890ab",
    "message": "Job created successfully"
  }
}
```

HTTP `404` means this key has no reservation visible to the current owner in
this deployment. Keep the same key when replaying an uncertain submission.
The existing [job status](/reference/api/job-status) endpoint reports execution
after acceptance; an accepted submission is not a completed job.

## Check deployment capabilities

Before using durable submissions, read `GET /v1/batch-capabilities` with the
same deployment key:

```bash theme={null}
curl --fail-with-body "${SUTRO_API_URL%/}/v1/batch-capabilities" \
  -H "Authorization: Key $SUTRO_API_KEY"
```

```json theme={null}
{
  "idempotent_submission": 1,
  "submission_owner_id": "22222222-2222-4222-8222-222222222222",
  "input_formats": ["csv", "parquet", "jsonl"],
  "result_formats": ["parquet"]
}
```

Require `idempotent_submission: 1` and the formats your client uses. Upgrade an
older deployment before submitting; do not fall back to an ordinary submission
when relying on safe replay. The
[Python SDK](/reference/python-sdk/functions#retry-safe-s3-submission) and
[CLI](/reference/cli/index#resumable-s3-batches) perform this check.
The CLI also preserves a local submission receipt automatically; Python callers
persist their key and request configuration.

`submission_owner_id` is the stable authenticated account ID. The CLI binds new
receipts to it and verifies it before replaying an unresolved submission, so API
key rotation for the same owner works while switching owners cannot create
another job from the saved source.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.