> For the complete documentation index, see [llms.txt](https://docs.tradevest.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.tradevest.ai/release-notes/archive/v.2.6.0.md).

# v.2.6.0

**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](/api-reference/asset-management/wawex-tokenized-assets/tokenized-assets.md)
* **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/asset-management/savings-plans.md) / API REFERENCE → [Webhooks](/api-reference/webhooks.md)
* **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](/api-reference/asset-management/savings-plans.md)
* **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](/api-reference/asset-management/savings-plans.md)
* **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](/api-reference/asset-management/wawex-tokenized-assets/tokenized-assets.md)
* **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/asset-management/trading.md) / API REFERENCE → Trading → [Digital Assets](/api-reference/asset-management/digital-assets.md)
* **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](/api-reference/asset-management/corporate-actions.md)
* **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](/api-reference/asset-management/corporate-actions.md)
* **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/documents.md) / API REFERENCE → [Entities](/api-reference/entities.md)
* **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).


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.tradevest.ai/release-notes/archive/v.2.6.0.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.