@insurance-broker/api-client 5.14.0 → 5.15.0

package/dist/schema.d.ts

@@ -121,7 +121,7 @@ export interface paths {
          *
          *     Refused on a charge that has already concluded — a settled one was paid and a cancelled one was never owed — rather than silently re-stamping an anchor. That refusal is `409` `urn:brokerplatform:problem:obligation-concluded` (#593), and it is not retryable. A `409` can also be the platform's concurrency conflict, `urn:brokerplatform:problem:concurrency-conflict` with `retryable: true`.
          *
-         *     A missing or over-long reason is `400` on `Reason`, the member's own name, which is the platform's majority convention; WorkflowComms' device and preference routes are the known exception (#613). It was `reason` until client 5.10.0 (#593).
+         *     A missing or over-long reason is `400` on `Reason`, the member's own name, which is the platform's convention on every module since #613. It was `reason` until client 5.10.0 (#593).
          */
         post: operations["WriteOffObligation"];
         delete?: never;
@@ -251,7 +251,7 @@ export interface paths {
          *
          *     **Each `409` carries a `type`** (#593): `urn:brokerplatform:problem:invoice-not-issued` (a draft or a discarded invoice), `urn:brokerplatform:problem:credit-note-exceeds-invoice` (credit less, counting the notes already issued) and `urn:brokerplatform:problem:idempotency-key-reused`. None is retryable.
          *
-         *     **Validation keys are the members' own names** — `Reason`, `Lines`, `IdempotencyKey` — which is the platform's majority convention; WorkflowComms' device and preference routes are the known exception (#613). They were camel-cased until client 5.10.0 (#593).
+         *     **Validation keys are the members' own names** — `Reason`, `Lines`, `IdempotencyKey` — which is the platform's convention on every module since #613. They were camel-cased until client 5.10.0 (#593).
          *
          *     **A retried credit note without a key credits the customer twice**, so send one. **`idempotencyKey` is optional, and it is what makes a retry after a lost response safe.** Without one, every request writes a new credit note. With one, a repeat carrying a key already used **answers the original credit note with the same `201 Created` and the same `Location`** and writes nothing; a repeat carrying that key with a **different** invoice, reason or set of lines is a `409` and writes nothing. The key is trimmed, at most 200 characters, blank is no key, and it belongs to this broker alone.
          *
@@ -521,7 +521,7 @@ export interface paths {
          * Take a copy of a document filed against a payment
          * @description PAY-003. Streams one file back, and only when the malware scan has passed it.
          *
-         *     **A `409` here is about the scan and not about the request.** `urn:brokerplatform:problem:document-scan-pending` means wait and ask again; `document-infected` and `document-unscannable` mean this file will never be served and another must be filed. The `type` is what tells them apart — all three are 409 so that a client branching on status alone still behaves safely.
+         *     **A `409` here is about the scan and not about the request.** `urn:brokerplatform:problem:document-scan-pending` means wait and ask again; `urn:brokerplatform:problem:document-infected` and `urn:brokerplatform:problem:document-unscannable` mean this file will never be served and another must be filed. The `type` is what tells them apart — all three are 409 so that a client branching on status alone still behaves safely.
          *
          *     **The response is verified as it is written.** If the store no longer holds what was filed, the transfer is aborted rather than completed over bytes nobody can vouch for.
          */
@@ -1986,7 +1986,7 @@ export interface paths {
          *
          *     The customer is named in the request and is not believed: it is checked against the policy, and the claim records the owner the policy gave.
          *
-         *     **`idempotencyKey` is optional, and it is the only thing that makes a retry safe.** Without one, sending the notification twice opens two claims. With one: a repeat carrying a key already used **returns the original claim and the same `201 Created` with the same `Location`**, so a retry after a lost response opens nothing new. A repeat carrying that key with a **different** policy, customer or incident day is a `409` and opens nothing.
+         *     **`idempotencyKey` is optional, and it is the only thing that makes a retry safe.** Without one, sending the notification twice opens two claims. With one: a repeat carrying a key already used **returns the original claim and the same `201 Created` with the same `Location`**, so a retry after a lost response opens nothing new. A repeat carrying that key with a **different** policy, customer or incident day is a `409` and opens nothing; it is typed `urn:brokerplatform:problem:idempotency-key-reused` (#614), and it is not retryable.
          *
          *     **A key is honoured for 30 days from the moment the claim was notified, and then stops being honoured.** After that the same key is one this platform has never seen. Mint a fresh key per form and reuse it only to retry that notification (#565). A key is shared by everybody at this broker — a colleague sending the same string meets the same claim — and is never shared with another broker, or with the key a customer sends when reporting a claim themselves.
          */
@@ -2550,7 +2550,7 @@ export interface paths {
          *
          *     To retract a claim, tell your broker. Concluding a case starts its retention clock, so it is recorded by the person who was told.
          *
-         *     **`idempotencyKey` is optional, and it is the only thing that makes a retry safe.** Without one, sending the report twice opens two claims. With one: a repeat carrying a key you already used **returns the original claim and the same `201 Created` with the same `Location`**, so a retry after a lost response opens nothing new. A repeat carrying that key with a **different** policy or incident day is a `409` and opens nothing.
+         *     **`idempotencyKey` is optional, and it is the only thing that makes a retry safe.** Without one, sending the report twice opens two claims. With one: a repeat carrying a key you already used **returns the original claim and the same `201 Created` with the same `Location`**, so a retry after a lost response opens nothing new. A repeat carrying that key with a **different** policy or incident day is a `409` and opens nothing; it is typed `urn:brokerplatform:problem:idempotency-key-reused` (#614), and it is not retryable.
          *
          *     **A key is honoured for 30 days from the moment the claim was reported, and then stops being honoured.** After that the same key is one this platform has never seen. Mint a fresh key per intended report and reuse it only to retry that report (#444). A key is yours alone: another customer sending the same string never meets your claim.
          */

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@insurance-broker/api-client",
-  "version": "5.14.0",
+  "version": "5.15.0",
   "description": "Generated TypeScript client for the Insurance Broker Platform API. Do not edit by hand: regenerate with scripts/update-api-contract.",
   "license": "UNLICENSED",
   "private": false,