Skip to main content

Outcome

Your message appears in the intended thread, or an open request-to-client has a schema-valid answer whose usable attachments completed processing.

Prerequisites

  • A Bearer key.
  • The exact order or mandate UUID and, for an answer, the request UUID and allowed_answer_types.
  • One stable idempotency key per create or answer command.

Answer a request during order review

An order can receive a request before acceptance into a mandate. When a request_to_client.created webhook carries order_id, use that order UUID and request_to_client_id with the order routes: For a yes-no question, send {"text": "yes", "documents": []} with your Bearer credential and an Idempotency-Key. The answer response is 200; a second answer with a different key returns 409. Question attachments expose authenticated download links. Answer documents can be uploaded inline or through /v2/orders/{order_id}/requests-to-client/{request_id}/answer/documents/; list, detail, download, and delete routes use the same parent. Documents remain editable only while the API answer’s staff review task is open and the order remains eligible for review. The order resumes after every published request is answered. Attachments continue processing asynchronously and can be downloaded when ready; replace failed or rejected files while the answer remains editable. An ordinary order message does not answer a request. The examples below use mandate requests. Order requests accept the same answer payloads at the corresponding order routes.

1. Create a mandate message

The 201 response is the created MessageRead resource, including its id. Use a command-unique title as well so you can find the message if the response is lost before you store that ID.
The 201 body of the create is the message read resource with its id; keep that id. This search is the recovery path when the create response was lost before the id was stored — match on the unique title you generated:
Follow every exact next URL. Match the command-unique title, mandate parent, and API author across the complete search, require exactly one stable server id, and use that ID for every later mutation.

Representative response

This complete response matches PaginatedMessageReadList.

3. Correct the exact open message

Mutation is allowed only while the server says editable: true; a closed staff review task returns 409 and must not be bypassed.

4. Read the exact request to client

5. Answer only the still-open typed request

This body is valid only for yes-with-date-no-freetext-on-no. Other modes restrict text, booking_date, and additional_comment exactly as described by allowed_answer_types; never answer an already answered request.

Runnable Python workflow

Python workflow
The search has a documented five-page example budget. Production code should configure a finite budget sized for its account while retaining cycle and same-origin HTTPS checks before every opaque next request.

Failure and recovery

  • 400: re-read allowed_answer_types; remove forbidden fields and add any required comment or booking date. A message title is a single line — control characters are control_characters, an empty title is blank. A message body is multi-line (TAB, LF, and CR accepted) and is sanitized; a body that is empty after sanitization is 400 on body with code blank, on create and on PATCH.
  • 400 documents / not_allowed: inline answer documents are accepted only on fileupload, freetext, yes-no-freetext-on-no, and yes-with-date-no-freetext-on-no requests. Remove them for every other type.
  • 400 blank / invalid on text or additional_comment: both fields are plain text — markup is stripped and entities decoded before validation. Send the words only; a value that is empty after stripping is blank, markup that does not converge to plain text is invalid.
  • 400 parse_error on /answer/documents/: that route uses the bounded JSON parser like every other write — non-finite numbers and nesting deeper than 64 levels are rejected before validation.
  • 403 on an answer: when the sandbox capability policy refuses the command (sandbox_feature_unavailable, sandbox_source_managed), the envelope adds translation_key — the key of the localized message that matches detail — so you can map the refusal without parsing detail.
  • 409: refetch the exact message or request. Never overwrite a closed review task or completed answer. Creating or editing a message (or its documents) on a withdrawn, rejected, or merged order is 409 conflict; use the surviving order named in merged_into, or the mandate once accepted.
  • 409 order_expired on an order message: the draft order expired; it takes no further messages. 409 conflict with Messages are disabled for this mandate.: messaging is switched off for that case, for new messages, edits, and message documents alike.
  • 404 on creating a mandate message: the mandate is a subcase; write to its main case. Existing subcase threads stay readable.
  • Timeout, 500, or 503: retry a POST with the same idempotency key.
  • A failed or rejected answer document is left out of the handoff to paywise; replace it while the answer remains editable if the evidence is still needed.

Verify

Follow every next URL and require exactly one row whose title equals the command-unique title you sent; record its id. For an answered request, read the request again and require answered_at to be set.