> ## Documentation Index > Fetch the complete documentation index at: https://diameterpay.mintlify.site/llms.txt > Use this file to discover all available pages before exploring further. # Diameter API Version History, Changelog, and Release Notes > Track all Diameter API changes: new features, breaking changes, and deprecations across every version from the current release back to v0.5.0. The Diameter API changelog documents every notable change across each release — including new endpoints, field additions, behavioral fixes, deprecations, and breaking changes. Review this page before upgrading your integration to any new version. Breaking changes are clearly marked with warnings, and migration guidance is provided where applicable. ## 0.11.7 > [!NOTE] > > **Account balance rate limiting** — The `GET /v1/accounts/{id}/balance` endpoint is now subject to a rate limit of **15 requests per second**. Requests exceeding this limit will receive a `429 Too Many Requests` response. * `GET /v1/accounts/{id}/balance` is now rate-limited to **15 requests/second**. Implement exponential back-off or caching of balance values in your integration to stay within this limit. *** ## 0.11.6 * Added account validation for payment simulations. The simulation endpoints now verify that the referenced account exists and is active before processing, returning a descriptive error if validation fails. *** ## 0.11.5 > [!NOTE] > > **Optional end-user name on account responses** — You can now request that account responses include the associated end user's name without a separate lookup. * Added optional `endUserName` field to account responses. Pass `includeEndUserName=true` as a query parameter to `GET /v1/accounts/{id}` or `GET /v1/accounts` to include the field. * When the query parameter is omitted, `endUserName` is not present in the response. *** ## 0.11.4 > [!NOTE] > > **New ID types for individual end users** — Two additional government-issued ID types are now accepted for individual end-user onboarding. * Added `DRIVING_LICENSE` and `NATIONAL_ID_CARD` as valid values for `idType` when creating individual end users. * `fullName` is **deprecated** as an input field on `POST /v1/end-users/individuals`. Any value you submit is silently ignored. The API now auto-constructs `fullName` from `firstName`, `middleName`, and `lastName`. The `fullName` field continues to appear in all responses. > [!WARNING] > > **Deprecation — `fullName` input on `POST /v1/end-users/individuals`:** Stop sending `fullName` in your request bodies. It is ignored today and may be rejected in a future version. Ensure your integration populates `firstName`, `middleName` (if applicable), and `lastName` instead. *** ## 0.11.3 * **Webhook delivery retries now only retry on temporary failures.** Retries are triggered exclusively for HTTP status codes `408`, `409`, `421`, `423`, `425`, `429`, and all `5xx` responses. Previously, any HTTP error code (including permanent client errors like `400` or `404`) would trigger retry attempts. * **Inactive webhook subscriptions are no longer retried.** If a subscription is marked inactive at the time of a delivery attempt, the retry is skipped entirely. > [!TIP] > > If your webhook endpoint was previously relying on retries after returning a `400` or `404` to signal processing failures, update your endpoint logic to return a `2xx` immediately on receipt and process events asynchronously. Use the `POST /v1/webhook-subscriptions/{id}/redeliver` endpoint (added in 0.10.0) if you need to replay events. *** ## 0.11.2 > [!NOTE] > > **`currency` field added to account responses and webhook payloads.** * Added `currency` field to account responses returned by `GET /v1/accounts/{id}` and `GET /v1/accounts`. * Added `account.currency` to the `ACCOUNT_CREATED` and `ACCOUNT_UPDATED` webhook event payloads. *** ## 0.11.1 > [!WARNING] > > **Idempotency key conflict behavior change:** `409 Conflict` is now returned in two distinct scenarios that previously may have behaved differently. Update your error-handling logic accordingly. * Reusing the same `Idempotency-Key` with a **different payload** now returns `409 Conflict` with error code `ERR_7006`. * Reusing the same `Idempotency-Key` while the **original request is still processing** now returns `409 Conflict` with error code `ERR_7003`. * Webhook subscription URL updates now validate the new domain against the tenant's allowed domain list. Requests with an invalid domain return `400 Bad Request`. * Organization end-user `website` field now accepts both domain-only format (`www.acme.com`) and full URL format (`https://www.acme.com`). *** ## 0.11.0 > [!NOTE] > > **`onboardedInBanks` replaces `onboardInBanks` in end-user responses** — A new field is introduced to more clearly communicate completed bank onboarding status. * Added `onboardedInBanks` to all end-user responses and to `END_USER_CREATED` / `END_USER_UPDATED` webhook payloads. This field lists all banks where the end user's onboarding is fully complete. * `onboardInBanks` is **deprecated** in responses — use `onboardedInBanks` going forward. The `onboardInBanks` field is still accepted as input on `POST` request bodies. * Fixed a webhook delivery bug where `END_USER_UPDATED` events triggered by onboarding status transitions could be delivered with incorrect payload data. * **Inline counterparty on wire payments:** `POST /v1/payments/wire/domestic` and `POST /v1/payments/wire/international` now accept a `creditor` inline object in addition to `creditorId`. You must provide **exactly one** of `creditorId` or `creditor`. Requests that include both, or neither, are rejected with a validation error. > [!WARNING] > > **Deprecation — `onboardInBanks` in responses:** The `onboardInBanks` field in end-user response bodies is deprecated. Migrate your response-parsing code to read `onboardedInBanks`. The deprecated field may be removed in a future version. > [!TIP] > > The inline `creditor` object on wire payment requests lets you submit a payment to a new counterparty in a single API call, without a separate `POST /v1/counterparties` step. The counterparty is created implicitly and linked to the payment. *** ## 0.10.0 > [!NOTE] > > **Webhook redelivery, automatic intermediary routing, and ASCII validation** — Three significant capability additions in this release. * **New endpoint:** `POST /v1/webhook-subscriptions/{id}/redeliver` — Redeliver webhook events for a given subscription. Supports two modes: * `specific`: provide up to 100 explicit event IDs to redeliver. * `query`: filter events by time window and delivery status. The time window may span a maximum of **7 days**. * **Automatic intermediary routing number resolution:** For counterparties with a `BIC` routing type, the API now automatically resolves the `intermediaryRoutingNumber`. You no longer need to look up or supply this value manually. * **ASCII-only character validation:** All text fields now enforce ASCII-only input. Name fields (`firstName`, `lastName`, etc.) accept `A–Z`, `a–z`, `0–9`, spaces, and tabs. All other string fields must contain only printable ASCII characters. * Organization `website` field is now validated as a well-formed URL. > [!WARNING] > > **ASCII validation is enforced immediately.** Requests containing non-ASCII characters (e.g., accented letters, Unicode symbols) in any text field will be rejected with a `400 Validation error`. Sanitize inputs in your integration before sending to the API. *** ## 0.9.0 > [!NOTE] > > **New account webhook events** — Your integration can now receive real-time notifications when accounts are created or updated. * Added two new webhook event types: `ACCOUNT_CREATED` and `ACCOUNT_UPDATED`, both using context type `ACCOUNT`. * Webhook payloads for these events include a full account snapshot with `accountNumber`, `bank`, and `wireInstructions`. *** ## 0.8.0 > [!NOTE] > > **New counterparty webhook events** — Your integration can now receive real-time notifications when counterparties are created or updated. * Added two new webhook event types: `COUNTERPARTY_CREATED` and `COUNTERPARTY_UPDATED`, both using context type `COUNTERPARTY`. * Webhook payloads include a full counterparty snapshot at the time of the event. *** ## 0.7.0 > [!WARNING] > > **Breaking change — Payment status values and webhook event types have been restructured.** Integrations that read payment statuses or handle payment webhook events must be updated before upgrading to this version. **Payment status simplification:** The following status values have been **removed**: `CHECKS_REQUESTED`, `CHECKS_PASSED`, `CHECKS_FAILED`, `SCREENING_FAILED`, `ENRICHED`, `SETTLED`, and others from the previous expanded set. The current supported payment statuses are: | Status | Description | | - | - | | `SCREENING_REQUESTED` | Payment submitted and awaiting compliance screening | | `SCREENING_PASSED` | Compliance screening completed successfully | | `ROUTED` | Payment routed to the partner bank | | `RECEIVED_BY_PARTNER` | Confirmed received by the partner bank | | `COMPLETED` | Payment fully settled | | `FAILED` | Payment failed at any stage | **Webhook event type changes:** The following outbound payment event types have been **removed**: `PAYMENT_WIRE_OUTBOUND_CREATED`, `PAYMENT_WIRE_OUTBOUND_MANUAL_REVIEW`, and others from the previous set. New outbound wire payment event types: * `PAYMENT_WIRE_OUTBOUND_SCREENING_REQUESTED` * `PAYMENT_WIRE_OUTBOUND_SCREENING_PASSED` * `PAYMENT_WIRE_OUTBOUND_ROUTED` * `PAYMENT_WIRE_OUTBOUND_RECEIVED_BY_PARTNER` * `PAYMENT_WIRE_OUTBOUND_COMPLETED` * `PAYMENT_WIRE_OUTBOUND_FAILED` New internal payment event types (mirroring the same lifecycle): * `PAYMENT_INTERNAL_SCREENING_REQUESTED` * `PAYMENT_INTERNAL_SCREENING_PASSED` * `PAYMENT_INTERNAL_ROUTED` * `PAYMENT_INTERNAL_RECEIVED_BY_PARTNER` * `PAYMENT_INTERNAL_COMPLETED` * `PAYMENT_INTERNAL_FAILED` > [!TIP] > > Map your existing event handlers from the old event type names to the new names above. The lifecycle semantics are equivalent — only the naming has changed to align with the simplified status model. *** ## 0.6.0 > [!NOTE] > > **Payment retrieval and search endpoints are now available.** * Added `GET /v1/payments/{id}` endpoint for retrieving a single payment by ID. Requires the `payments:read` scope. * Added `POST /v1/payments/search` endpoint for searching payments by `paymentId` or `endToEndId`. * Payment response objects now include the following new fields: * `e2eId` — end-to-end payment identifier * `wire.initialImad` — initial IMAD assigned at submission * `wire.finalImad` — final IMAD assigned after settlement * `idAssignedByBank` — the ID assigned by the partner bank *** ## 0.5.0 > [!WARNING] > > **Breaking change — Scope-based authorization and standardized error responses are required.** All API clients must use JWT tokens with the correct scopes and update error-handling logic to match the new error response format. **Scope-based authorization:** All API endpoints now require JWT access tokens that include the appropriate scope claim. Scopes follow the format `{resource}:{permission}` (e.g., `accounts:read`, `payments:write`). Requests with tokens missing the required scope receive `403 Forbidden`. **Standardized error response format:** All error responses now follow a consistent structure: ```json theme={null} { "requestId": "550e8400-e29b-41d4-a716-446655440000", "timestamp": 1704067200000, "error": { "statusCode": 400, "message": "Validation failed for the submitted data.", "code": "ERR_1301", "severity": "error", "details": [ { "location": "body", "path": "email", "message": "Email format is invalid", "reason": "invalid" } ] }, "metadata": {} } ``` Update all error-handling code to read `error.code`, `error.statusCode`, and `error.details` from this structure. The `requestId` field is useful when contacting support for incident investigation. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.