Skip to main content
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

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

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

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.
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.
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

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

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

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.
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.
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

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.
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

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

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

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: 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
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

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

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:
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.