2.6.0 Release Archive

v.2.6.0

2026-06-23 - Live 2026-06-09 - Test Environment

2026-06-23 - Live

2026-06-09 - Test Environment

Added

Tokenized Assets: EXPIRED Order Status

The WAWEX (tokenized asset) order status enum gains a new terminal status for orders that expire before being filled - completing the lifecycle alongside PARTIALLY_FILLED_EXPIRED introduced in v.2.5.0.

  • Documentation Location: API REFERENCE → Trading → Tokenized Assets
  • Affected Schema: OrderStatus on GET /wawex/orders/{orderId} and related WAWEX order responses
  • Added: EXPIRED - order expired before any execution took place
  • Note: Partners using strict enum validation on WAWEX order responses must add EXPIRED to their accepted set alongside the existing values.

Changed

Savings Plans: startDate / endDate Lifecycle

Savings plans now carry explicit start and end dates. startDate is required on creation and determines when the first execution occurs; the optional endDate causes the plan to be transitioned to DELETED by the nightly expiry job once it passes.

  • Documentation Location: API REFERENCE → Trading → Savings Plans / API REFERENCE → Webhooks
  • Endpoints: POST /savings-plans, GET /savings-plans/{savingsPlanId}, savings plans webhook
  • Added required field on POST /savings-plans request: startDate (string, date) - must be today or a future date
  • Added optional field: endDate (string, date) - must be strictly after startDate
  • Added fields on SavingsPlan response and SavingsPlansNotification webhook payload: startDate, endDate
  • Note: This refines the savings plans contract before any partner has integrated against it on Live. Partners that began wiring against the v.2.4.x / v.2.5.0 Pretest spec must include startDate on every new POST /savings-plans request and accept the two new fields on the GET response and webhook.

Savings Plans: savingPlanId → savingsPlanId Rename and Type Tightening

Spec cleanup pass: the savings-plans contract is now internally consistent on field naming, enum types, and currency references.

  • Documentation Location: API REFERENCE → Trading → Savings Plans
  • Endpoints: POST /savings-plans, GET /savings-plans/{savingsPlanId}, PATCH /savings-plans/{savingsPlanId}, DELETE /savings-plans/{savingsPlanId}, GET /customers/{customerId}/savings-plans
  • Path parameter renamed: {savingPlanId} → {savingsPlanId}
  • Response field renamed: savingPlanId → savingsPlanId on SavingsPlan (required field)
  • Type change: intervalDay is now integer with enum values 1, 16 (previously string with '1', '16')
  • Schema change: currency now references CurrencyEnum (previously a free-form ISO 4217 string)
  • Enum typing: InstrumentTypeEnum, SavingsPlanIntervalPeriodEnum, SavingsPlanIntervalDayEnum now declare explicit type: string / type: integer for stricter client codegen
  • Note: This refines the savings plans contract before any partner has integrated against it on Live. Partners that started wiring against the v.2.5.0 Pretest spec must (a) use savingsPlanId consistently in path and body, (b) send/parse intervalDay as an integer, and (c) restrict currency to CurrencyEnum values.

Savings Plans: Requestor-ID Header Required on Write Endpoints

Write operations on savings plans now require the standard Requestor-ID header, aligning the API with the rest of the Tradevest Partner API write surface.

  • Documentation Location: API REFERENCE → Trading → Savings Plans
  • Endpoints: POST /savings-plans, PATCH /savings-plans/{savingsPlanId}, DELETE /savings-plans/{savingsPlanId}
  • Added header (required): Requestor-ID - UUID identifying the natural person initiating the action
  • Note: This refines the savings plans contract before any partner has integrated against it on Live. Partners must include Requestor-ID on every write call to savings plans; calls without the header will be rejected with 400 Bad Request.

Tokenized Assets: side → tradeSide Rename

The order-direction field on WAWEX orders is renamed for consistency with the rest of the Tradevest Partner API (tradeSide is already used elsewhere in the trading domain).

  • Documentation Location: API REFERENCE → Trading → Tokenized Assets
  • Endpoints: POST /wawex/orders (request), GET /wawex/orders/{orderId} (response), related WAWEX order responses
  • Renamed (required field): side → tradeSide (values from TradeSideEnum unchanged: BUY, SELL)
  • Note: This refines the WAWEX contract before any partner has integrated against it on Live. Partners that began wiring against the v.2.5.0 Pretest spec must rename side → tradeSide in both request payloads and response parsers.

Digital & Traditional Assets: savingsPlan → savingsPlansEligible Rename

The savings-plan eligibility flag on the asset list endpoints is renamed to be self-describing, and the unused savingsPlanMinAmount field is dropped.

  • Documentation Location: API REFERENCE → Trading → Traditional Assets / API REFERENCE → Trading → Digital Assets
  • Endpoints: GET /digital-assets, GET /traditional-assets
  • Query parameter renamed: savingsPlan → savingsPlansEligible
  • Response field renamed (required): savingsPlan → savingsPlansEligible on DigitalAsset and TraditionalAsset
  • Removed field: savingsPlanMinAmount (was unused - minimum amounts are returned via the dedicated savings-plans configuration)
  • Note: This refines the savings-plan eligibility surface before any partner has integrated against it on Live. Partners that used the previous savingsPlan filter or response field must switch to savingsPlansEligible.

Corporate Actions: responseDeadline Format Now date-time

The responseDeadline field on corporate actions now carries a full timestamp (date + time + zone) instead of just a date - required to express the cut-off down to the hour for tender (TEND) instructions.

  • Documentation Location: API REFERENCE → Trading → Corporate Actions
  • Endpoints: GET /corporate-actions/, GET /corporate-actions/customers/{customerId} (and the per-id detail endpoint)
  • Changed field: responseDeadline - format: date → format: date-time (e.g. 2024-01-14T12:31:13.000Z instead of 2024-01-14)
  • Required Partner Action: If a partner parses responseDeadline against a strict date parser, update the parser to accept ISO-8601 date-time. Existing date-only values will no longer appear in responses.

Corporate Actions: postedCash → fractionalCashAmount Rename and Conditional-Field Clarifications

The cash-in-lieu-of-fractional-shares field is renamed to be self-describing. Several optional fields now document the corporate-action subtypes that actually require them.

  • Documentation Location: API REFERENCE → Trading → Corporate Actions
  • Endpoints: GET /corporate-actions/, GET /corporate-actions/customers/{customerId} (request schema and customer-event response schema)
  • Renamed field: postedCash → fractionalCashAmount on both the corporate-action and corporate-action-customer-event schemas
  • Description clarifications (no schema change):
    • grossAmount - Required for DVCA
    • ratioFrom, ratioTo - Required for SPLF / BONU / DVSE
    • responseDeadline - Required for TEND
  • Required Partner Action: Partners parsing the postedCash field must rename to fractionalCashAmount. The conditional-field documentation describes existing server behavior - no client change is required.

Documents & Entities: Documentation Refinements

Two doc-only updates to clarify partner-facing behavior that was previously implicit.

  • Documentation Location: API REFERENCE → Documents / API REFERENCE → Entities
  • Contact (PATCH) semantics: Both Contact and ContactUpdate schemas now carry an explicit notice that the contact object requires a full representation on PATCH. Omitted optional fields (e.g. fax, website) are persisted as null. Partners must include all current contact values on update to preserve them.
  • Document-type matrix: documents.yaml now lists W_8BEN and W_8IMY alongside W_8BEN_E in the Tax-documents row for LEGAL_ENTITY (the enum values themselves were already added in v.2.5.0).