Changelog

(2026-09-24, Phase 10 close-out review: 526 paths, 660 operations, 849 schemas). One additive enum value for integrators; the rest tightens staff operations:

• Neutral review holds. Hold.subject.type adds payment_review: funds reserved while a payment is processed (for example an incoming credit under review). Its subject.id is the hold's own id and its description is neutral; the amount counts against the available balance like any other hold. Clients that switch on the subject type should treat unknown values as a generic reservation.
• Step-ups on policy writes (staff). PUT /operators/{operatorId}/settings needs the mfa.change step-up when it changes security, approvedEmailDomains or apiKeyInvitationDomains. PUT /platform/compliance/defaults needs the new capability platform.compliance, an X-Access-Reason and the compliance.gate_settings_change step-up.
• Status unsubscribe limit. POST /public/status/subscriptions/unsubscribe is limited per unsubscribe token (5 an hour), not per address, so mail providers' one-click unsubscribes are never refused for sharing an address.
• New capability. platform.compliance (WireBloom super admins).

Also in draft.14 (2026-09-25, Phase 11/12 residual wave: 529 paths, 664 operations, 856 schemas). Additive: no operation, schema or property was removed and no request field became required. Clients with strict enums or strict status-code handling should read the 202 items:

• Batch id look-ups (filter[id]). GET /recipients, /customers, /ops/customers, /balances and /platform/operators accept filter[id]=<id>,<id>,… (at most 100; above that 400 too_many_filter_values) and return only those rows; unknown or foreign ids are absent. Send limit ≥ the number of ids.
• Counts (withTotal). GET /approvals gains withTotal (already served by /recipients, now declared); limit=1&withTotal=true is the count-only form for badges. On every list, page.total is computed on the first page only (a request without cursor).
• Conditional GET (ETag). GET /notifications, /notifications/unread-count, /approvals and /documents return a weak ETag; send it back as If-None-Match when polling and the API answers 304 without a body while nothing changed.
• Processing ETA. Payment.processing (PaymentProcessing: status queued, position, etaSeconds, estimatedAt) is present while an approved, due payment waits in the operator's submission queue, and absent once submitted.
• Approval-policy dual control. ApprovalSubjectType adds approval_policy_change. PUT /customers/{customerId}/settings/approval-policies/{kind} answers 202 with the unchanged live policy and ApprovalPolicy.pendingChange when the edit loosens control and another owner or admin exists; that person decides it through /approvals/{id}. Approval.subjectSummary adds recipientMaskedIdentifier.
• Batch-rail imports under four eyes (staff). POST /ops/batch-rail/connections/{connectionId}/imports answers 202 with a StaffApproval (batch_import) when four eyes apply (always for a production connection); POST …/imports/{fileId}/statement reconciles the credits of a proposed import against the bank statement before it can be approved.
• Operator offboarding under four eyes (platform). POST /platform/operators/{operatorId}/offboard answers 202 with an OperatorOffboardRequest on the first platform user's call; a different platform user's call within 24 hours offboards (200).
• OAuth consent. GET /auth/oauth2/authorize no longer mints a code: with a web session it redirects to the web consent page, which confirms with the new POST /auth/oauth2/authorize (OAuthConsentRequest → OAuthConsentResponse.redirectUrl). Mobile apps using the system-browser flow need no change beyond the one consent tap.
• Also new. GET /ready (readiness; 503 while the instance cannot serve, GET /health stays liveness), POST /billing-runs/previews (billing dry run as a job, 202 + Job), six step-up actions and x-step-up on every platform write and on the remaining operator money and policy writes, the chain and roll-up fields of AuditChainStatus, a 92-day window for free-text audit search (q), 202 from POST /me/email-change whether or not the address is in use, and per-IP 429s on anonymous routes and inbound provider webhooks.

All additive for integrators except the new step-ups on key revocation and webhook changes; staff endpoints need operator staff sessions unless an operator-key scope is listed:

• Developer portal and published contract (P9-T07). GET /v1/openapi.json (tag public-api, no authentication) serves this contract as JSON in every environment with Cache-Control: public, max-age=300, a strong ETag (304 on If-None-Match) and X-Contract-Version. Swagger UI at /docs stays internal (DOCS_ENABLED); in production /docs redirects to https://developers.wirebloom.com/reference. A deprecated operation's Link: <…>; rel="deprecation" points to https://developers.wirebloom.com/deprecations#{operationId}; deprecations can be declared in the contract (deprecated: true with x-deprecated-at and x-sunset, optional x-deprecation-link). Problem type URIs (https://api.banking.wirebloom.com/problems/{slug}) redirect to https://developers.wirebloom.com/errors#{slug}.
• API usage and integration home (P9-T11). Customers: GET /developer/api-usage (daily usage per key: requests, client and server errors, rate-limit hits, average duration, last use; from/to up to 90 days, apiKeyId, environment) and GET /developer/api-keys/{apiKeyId}/requests (the last 100 requests of a key over 7 days with a status breakdown; method, route template, status, duration and request id only, never bodies), api-keys.manage. Operator staff: GET /integration, GET /integration/api-usage and GET /integration/api-keys/{apiKeyId}/requests (integration.view, operator owners and admins; also operator-level keys with integration:read): banking connections with health, breaker, webhook registration, backlog, reconciliation and checklist progress, key counts, usage across every key, integrator webhook health and portal links. A call appears within about 5 seconds.
• Operator-level API keys and webhooks (P9-T08b, §2.1, §8.1, §8.2). /api-keys and /integrator-webhooks are x-tenant: any; ApiKey.level; ApiScope adds customers:read, customers:write, onboarding:read, treasury:read, reports:read, integration:read; the operator routes listed in §2.1 declare x-api-key-scopes. IntegratorEventType adds the six operator-only types; IntegratorEvent adds customerId and data.related; data.object adds customer and compliance_hold. Step-ups: DELETE /api-keys/{id} needs api_key.revoke; creating, updating, deleting and rotating the secret of an integrator webhook endpoint need integrator_webhook.change (sessions only; API keys are not subject to step-up).
• SDKs and Postman (P9-T08, §13). TypeScript and Python SDKs, generated C#, Java, PHP and Go clients, shared webhook test vectors and a Postman collection with environments, all versioned 1.0.0-draft.13.
• Developer programme and simulations (P9-T09). Public sign-up for an operator's sandbox: GET /developer/registration-options?operator=<slug>, POST /developer/registrations (always 202) and POST /developer/registrations/verify (201 with the workspace and the first wb_test_ key). GET /developer/workspace and GET /simulations (balances:read) plus the simulation operations under /simulations/* (sandbox keys only). Staff: /ops/developer-programme, /ops/developer-invitations, /ops/developer-registrations* (developers.manage) and /ops/simulations/provider-webhooks. Me.developerWorkspace tells a client the active customer is a sandbox workspace; BrandingPublic.slug gives the operator slug for the sign-up link.
• Status page and support (P9-T10). GET /public/status and /public/status/subscriptions* (no authentication, double opt-in), GET /status (any member: the platform page and the operator's private page), staff /ops/status* (status.manage: incidents, updates, component overrides, subscribers). Support requests: POST /support/requests, GET /support/requests[/{id}] (any member, self.profile) and the staff inbox /ops/support-requests* (support.manage).
• VIBAN pools, partner assets and account identifiers (P10-T04, P10-T06). Customers: GET /account-identifiers (the customer's VIBANs, including identifiers closing after a re-issue or provider switch) and GET /account-identifiers/{identifierId}/letter (PDF details letter), details.view. New customer-level event balance.details_changed: a balance's account identifier changed (data.status = reissue, provider_switch or closing); fetch GET /account-identifiers for the new details and tell your payers. Staff (operator.providers): /ops/viban-pools*, /ops/vibans/{vibanId}/{close,reissue,currencies}, /ops/viban-detail-changes* and GET /ops/partner-assets (with filter[expiringWithinDays]); new step-ups viban.pool_change, viban.lifecycle and partner_assets.change.
• Provider costs, packs and open banking (P10-T05, P10-T08). Staff: /ops/provider-costs* (provider-costs.view / provider-costs.manage: costs, margin, imports, ingest, monthly close), /ops/resolution-packs* (resolution-packs.manage) and /ops/regulatory-packs* (regulatory-packs.view / regulatory-packs.generate); downloads need the step-ups resolution_pack.download / regulatory_pack.download. Customers: GET /connected-apps, GET /connected-apps/{appId} (open-banking.view) and POST /connected-apps/{appId}/revoke (open-banking.manage), the third-party apps with open banking consent on the customer's accounts.
• New capabilities. integration.view, developers.manage, status.manage, support.manage, platform.status, provider-costs.view, provider-costs.manage, resolution-packs.manage, regulatory-packs.view, regulatory-packs.generate, open-banking.view, open-banking.manage (hyphenated names; clients match them as opaque strings).

All additive for integrators; the new staff endpoints need operator staff sessions:

• Documents requested inbox (customers). GET /document-requests, GET /document-requests/{requestId} and POST /document-requests/{requestId}/fulfil (tag activity, capabilities document.view / document.upload) are the one inbox for every document the operator asks for, whether for a partner compliance case or enhanced due diligence. DocumentRequest carries kind, title (null for partner-case requests: show the kind), documentTypes, message, status (requested, fulfilled, cancelled), dueAt, customerNote and the uploaded documents; never the case or its reason. Each request is announced by the generic document_requested notification. Upload with POST /documents first, then fulfil with the document ids (422 document-not-clean until the scan passed). The interim /compliance/document-requests routes of the P10-T02 drafts were never released and are removed.
• Partner compliance cases (staff). /ops/cases* (tag operator-ops; cases.view, cases.respond, cases.approve): Banking Circle RFIs and inbound recall requests with their timeline, links, notes, documents, customer document requests, RFI answers, a four-eyes recall decision and POST /ops/cases/sync.
• Compliance-as-a-service (staff). /ops/compliance/* (holds, queue, report, screening hits, recipient screening and rescreen, monitoring suppressions, gate settings, EDD cases and the review of documents customers provided), POST /ops/compliance/escalations, /ops/mlro/* (nominated officers, suspicion reports, DAML) and /platform/compliance/defaults (tag compliance; compliance.view, compliance.manage, compliance.decide, mlro.decide). Payments held by the compliance gate stay on_hold until staff release or block them.
• Integrated Finance sync (staff). GET /provider-connections/{connectionId}/sync, GET …/sync/links, POST …/sync/backfill, POST …/sync/drift and POST …/sync/links/{linkId}/resolve (tag providers, operator.providers).
• New step-up actions. cases.recall_decision, compliance.hold_decision, compliance.screening_decision, compliance.suppression, compliance.edd_decision, mlro.designation, mlro.sign_off; the sync backfill, drift and conflict resolution use provider_connection.change.
• New enum values. PaymentExceptionKind adds compliance_hold; reconciliation exception kinds add sync_conflict; staff approval kinds add compliance_hold_release. Clients with a strict enum must accept them.
• Tipping-off. Staff-written customer text (partner-case and EDD document requests) is checked by one shared guard and refused with 422 error code tipping_off.

• Customer types. Customer.customerType is business, sole_trader or individual (POST /customers takes it; identityType is derived: corporate for businesses, individual otherwise). A legacy create with identityType: individual becomes customerType: individual and its registrationNumber is dropped. Sole traders and individuals complete the personal section of KybCase (names, date of birth, nationality, residential address) instead of the company, address and ownership steps; an individual sends no company section and a sole trader only tradingName, incorporationCountry, industryCode and website (409 otherwise). The verified identity (names, date of birth, nationality) cannot change once the identity check started (409 identity_locked). Clients that switch on identityType keep working; clients that treat every customer as a company must handle the two new types.
• Metadata. Payments, recipients, balances and customers carry metadata: at most 20 keys ([A-Za-z0-9_-]{1,40}), string values of at most 500 characters, 8 KiB in total. List operations that support it take up to 5 filter[metadata.<key>]=<value> parameters (ANDed). Metadata is integrator-owned and unverified: never base authorisation decisions on it.
• Rails. New rail values target2, ach, wire and eft, offered only when the operator's active connection reports them. Clients with a strict Rail enum must accept the new values.
• Purpose codes. GET /payments/purpose-codes lists the catalogue per currency, destination and rail. Payments in CNH must carry one of GOD, STR, CTF, OTF (422 purpose_required / invalid_purpose). Elsewhere purposeCode is optional and any ISO 20022 ExternalPurpose1Code (4 letters) is accepted; a partner whose rail only takes a closed list drops a code outside it rather than failing the payment. Free text that is not a 4-letter code is refused (422 invalid_purpose).
• Routing codes. Recipient.bank.routingCodes takes cnaps, bankCode and branchCode (with country requirement sets for CN and other markets in GET /recipients/requirements).
• Bulk submit stays asynchronous (202, draft.10).

Breaking changes for operator tooling (operator console and staff API keys only; integrator endpoints are unaffected):

• ProviderConnection.status is the lifecycle ConnectionLifecycle (draft, configured, testing, active, draining, retired); disabled and error are gone (filter[status]=error answers 400). Health is healthy / lastHealth.
• PATCH /provider-connections/{connectionId} no longer takes status (422, the body is strict). Go live with POST …/activate (activation checklist), stop new work with POST …/drain and retire with POST …/deactivate (step-up provider_connection.change; 409 connection-in-use while balances, settlement money, in-flight items or active mandates remain). POST …/test verifies but never activates.
• POST /provider-connections refuses customerId (422): an operator has one active banking connection per environment.
• A live connection's config change may not remove what its activation checklist required (for example the Banking Circle inboundIpAllowList in production) nor change Integrated Finance webhook keys (409); configured Integrated Finance keys may only add new key versions on sandbox connections (422 reserved_version / not_allowed).
• New staff endpoints: GET …/activation, …/webhooks (registration, keys, subscriptions, test), POST …/webhook-token/rotate, and /ops/treasury/* (operator treasury payments and FX under dual control, approval with step-up treasury.approve).

POST /bulk-payments/{bulkPaymentId}/submit is asynchronous. It returns 202 with BulkPaymentSubmitAccepted (a Job plus the batch in submitting, header Location: /v1/jobs/{jobId}); poll GET /jobs/{jobId} for progress and GET /bulk-payments/{bulkPaymentId} for the final submitted / partially_submitted status and row results.