---
title: "Update compliance answers"
method: POST
path: "/v1/compliance/submissions/{submission_id}/resupply"
tags: ["compliance"]
---

# Update compliance answers

`POST /v1/compliance/submissions/{submission_id}/resupply`

## Request

- Base URL: `https://us1.platform.bird.com`
- URL: `https://us1.platform.bird.com/v1/compliance/submissions/{submission_id}/resupply`
- Auth: one of:
  - HTTP bearer
  - API key in cookie `bird_session`

Replaces rejected, expired, or missing answers on an existing submission. Accepted answers
normally cannot be changed and should be omitted.

When a verifier requests corrections, you can replace selected accepted answers while that
correction remains open and before its deadline. Unchanged entries are ignored, and at least one answer must change.
Changed answers are reviewed again; other answers remain unchanged.

The answers are a legal representation under the name of the business they describe. Accepted
dossiers can be registered with the carrier or regulator after compliance review.

## Headers

- `Idempotency-Key` string
- `X-Workspace-Id` string
- `X-Organization-Id` string

## Request body

- ComplianceSubmissionResupply: Replacement answers for an existing submission. Rejected, expired, or missing answers can be supplied again; accepted answers normally cannot be changed. When the requirements response marks an accepted answer as `editable_for_verifier_repair`, you can replace it during that open correction and before its deadline. Accepted-answer repairs must change content; unchanged accepted entries are ignored. Rejected, expired, or missing answers follow the ordinary resupply rules, including same-value retries after a grant is withdrawn. Supplied replacements are reviewed again.
  - `answers` ComplianceAnswer[], required
    - union: One answer. Which field carries it follows from the requirement, as the requirements read reports it: - answered once, inline: `value` - answered once, with a document: `attachment_id` - `max_items` set, inline: `values` - `max_items` set, with documents: `attachment_ids` Send exactly one of the four. Order in a list is preserved and is part of the answer.
      - object
        - `key` string, required: The requirement this answers, as given by its key in the requirements read.
        - `value` string, required: The answer, for a requirement answered inline. Send every answer as a string whatever its data type, so a number goes as `"1500"` and a yes-or-no as `"true"`.
        - `attachment_id` string
        - `values` string[]: The answers, for a requirement whose `max_items` is set and which is answered inline. Send each as a string whatever its data type, and send them in the order you mean them to be read. At most `max_items` of them.
        - `attachment_ids` AttachmentID[]: The uploaded documents, for a requirement whose `max_items` is set and which takes documents. Upload each file first and send the ids it returns, in order. At most `max_items` of them.
      - object
        - `key` string, required: The requirement this answers, as given by its key in the requirements read.
        - `value` string: The answer, for a requirement answered inline. Send every answer as a string whatever its data type, so a number goes as `"1500"` and a yes-or-no as `"true"`.
        - `attachment_id` string, required
        - `values` string[]: The answers, for a requirement whose `max_items` is set and which is answered inline. Send each as a string whatever its data type, and send them in the order you mean them to be read. At most `max_items` of them.
        - `attachment_ids` AttachmentID[]: The uploaded documents, for a requirement whose `max_items` is set and which takes documents. Upload each file first and send the ids it returns, in order. At most `max_items` of them.
      - object
        - `key` string, required: The requirement this answers, as given by its key in the requirements read.
        - `value` string: The answer, for a requirement answered inline. Send every answer as a string whatever its data type, so a number goes as `"1500"` and a yes-or-no as `"true"`.
        - `attachment_id` string
        - `values` string[], required: The answers, for a requirement whose `max_items` is set and which is answered inline. Send each as a string whatever its data type, and send them in the order you mean them to be read. At most `max_items` of them.
        - `attachment_ids` AttachmentID[]: The uploaded documents, for a requirement whose `max_items` is set and which takes documents. Upload each file first and send the ids it returns, in order. At most `max_items` of them.
      - object
        - `key` string, required: The requirement this answers, as given by its key in the requirements read.
        - `value` string: The answer, for a requirement answered inline. Send every answer as a string whatever its data type, so a number goes as `"1500"` and a yes-or-no as `"true"`.
        - `attachment_id` string
        - `values` string[]: The answers, for a requirement whose `max_items` is set and which is answered inline. Send each as a string whatever its data type, and send them in the order you mean them to be read. At most `max_items` of them.
        - `attachment_ids` AttachmentID[], required: The uploaded documents, for a requirement whose `max_items` is set and which takes documents. Upload each file first and send the ids it returns, in order. At most `max_items` of them.

## Response `200`

The submission, with your replacement answers on it.

- ComplianceSubmission
  - `next` NextAction[]: What to do next about this submission, given the state it is in. Each entry names one action and says why it is worth taking, so you can act on this response without working out the order yourself. Present on reads that compute it: an empty list means there is nothing to do, and the field is absent entirely on responses that do not report next actions. A submission reports the answers you filed; whether the country's requirements are met is reported by the requirements read. So this points there rather than repeating a verdict it does not own.
    - `kind` string, required: What you do about this step. - `operation`: call the operation named in `operation`, then read again. - `external`: act somewhere this API does not reach, then read again. - `wait`: nothing is asked of you, so read again later. - `terminal`: nothing you do resolves this, so stop retrying. Tolerate a value you do not recognize: show the `description` and offer no action.
    - `description` string, required: A short, human-readable label for the step, suitable for display.
    - `operation` string: The operationId to call. Present only when `kind` is `operation`. The operation's own schema says how to call it; this says only which one, and what to address it with.
    - `params` object: The parameters that address the operation, by name: `{"sender_id": "…"}` for an operation on `/v1/sms/senders/{sender_id}/requirements`. A parameter the operation takes in its query string is given the same way, so an operation addressed as `?subject_id=` carries `{"subject_id": "…"}`. Every parameter the call needs is here, whether its value came from the thing you were acting on or is fixed for this step, so you can make the call from this object alone. Present only when `kind` is `operation` and the operation names a subject. A request body, when the operation takes one, is described by the operation's own schema and never appears here.
    - `url` string, uri: A URL to open. Present only when `kind` is `external`, and only when the step has one. An external step whose `description` says to go and do something with no URL to open is normal.
  - `id` string, required
  - `subject_kind` 'sms_sender' | 'number' | 'identity', required: What is being registered. - `sms_sender`: a sender registered to send to one country. - `number`: a phone number you hold that needs ownership paperwork before it can carry traffic. - `identity`: a business you operate as, registered once and reused by later registrations that name it.
  - `subject_id` string, required: What is being registered. For `sms_sender` this is the `scr_` id returned when you register a sender for a country. For `number` it is the `nda_` id of a dedicated number you hold, as returned by `GET /v1/numbers`. A shared short code (`nal_`) is not accepted: it is shared, so its ownership paperwork is not yours to file. For `identity` it is the `cid_` id of the party being registered, picked from the parties your workspace holds, as returned by `GET /v1/compliance/identities`.
  - `program` string, required: The registration program a country runs. Available programs depend on the registered resource. An SMS sender registers under an authority regime (`alpha` or `numeric`). A phone number proves ownership under its number type (`mobile`, `local`, `national`, `short_code`, `short_code_fteu`, or `toll_free`), matching the values of `NumberType`. An identity registers your business itself under `business`, internationally: its coordinate's country is always `ZZ`. A value is therefore only meaningful alongside the subject it describes. More are added as coverage grows, so treat this as an open set rather than a fixed list.
  - `country_code` string, required: ISO 3166-1 alpha-2 country code.
  - `identity_id` string, required
  - `satisfied` boolean, required: Whether this country's requirements are met. `true` once the submission is approved and every required requirement is approved or marked not applicable. This can remain true when an external verifier requests a correction. Once you submit that correction, it must pass review before this becomes true again, including any optional answers you change.
  - `items` ComplianceSubmissionItem[], required: Every answer and where it stands. Each is decided on its own.
    - `inherited` boolean, required: `true` when this answer was accepted without a fresh review, because the same answer to the same requirement had already been approved for this party in this country. It carries the original verdict, including when that verdict expires.
    - `id` string, required
    - `key` string, required: The requirement this answers.
    - `state` string, required: Where one requirement stands. The `not_supplied` state means nothing has been given for it yet. The `supplied` state means we have your answer and review has not started. The `in_review` state means someone is looking at it. The `approved` and `rejected` states are decisions. You can replace a rejected item without refiling the rest. The `not_applicable` state means this requirement does not apply to you. The `expired` state means the value was accepted but has since gone stale. An item only ever reports its state. Treat this as an open set because review can gain stages. A value you do not recognise is a valid state that this server added.
    - `value` string, nullable, required: Your answer, for a requirement answered inline. Every answer travels as a string whatever its data type, so a number reads back as `"1500"` and a yes-or-no as `"true"`. Use the data type to parse it. `null` for a requirement that takes a document.
    - `attachment_id` string, required
    - `values` string[], nullable, required: Your answers, for a requirement that takes several and is answered inline. `null` for one answered once. Order is as you sent it.
    - `attachment_ids` AttachmentID[], nullable, required: The documents you supplied, for a requirement that takes several. `null` otherwise.
    - `reason` string, nullable, required: Why this was rejected, when it was. `null` otherwise.
    - `decided_at` string, date-time, nullable, required: When this was decided. `null` while no decision has been made.
    - `expires_at` string, date-time, nullable, required: When this answer goes stale and must be supplied again. `null` when it does not expire.
  - `created_at` string, date-time, required: When this was submitted.
  - `updated_at` string, date-time, required: When it last changed.
  - `closed_at` string, date-time, nullable: When this submission was closed. Null while it remains open.
  - `closure_reason` string, nullable: The decline reason for a closed submission, or null while open.

## Other responses

- `400`: Bad request
- `401`: Authentication required
- `403`: Insufficient permissions
- `404`: Resource not found
- `409`: Resource conflict
- `422`: The request has invalid field values, violates a business rule, or carries a query parameter the endpoint does not declare. Field validation errors use `type: validation_error` and include the affected fields in `details`. Business-rule errors identify the failed rule in `type`.
- `429`: Rate limit exceeded
- `500`: Internal server error
- `503`: The service is temporarily unavailable. If `Retry-After` is present, wait for that delay before retrying; otherwise, retry with exponential backoff. Reuse the same idempotency key and request when retrying a mutation.

## Changes

- **2026-10-20** `a1977645a499`: 1 info
  - endpoint added
- **2026-10-20** `6cec81ac4862`: 1 breaking
  - api path removed without deprecation
- **2026-10-20** `3e2a50466454`: 1 info
  - endpoint added

[Operation history](https://skmtc.dev/messagebird/apis/bird-api/changes/v1/compliance/submissions/:submission_id/resupply/post.md)

---

[API](https://skmtc.dev/messagebird/apis/bird-api.md) · [All operations](https://skmtc.dev/messagebird/apis/bird-api/llms.txt) · [OpenAPI document](https://skmtc.dev/messagebird/apis/bird-api/revisions/483bb7bfdc89?raw)