POST /requests: Payload schema to accept and create standard spread requests, automatic detection if it's standard spread.

Quoting Endpoints: Updated POST .../price-proposals, POST .../individual-counteroffers, and POST .../quotations to accept the EntenderQuoteStandardSpreadAdd object carrying a single spread-price.

GET .../analytics: Added StandardSpreadAnalytics support (type: standard-spread) matching the standard SingleAnalytics payload structure.

Enums: Extended SpreadType with time, location and efp. Added standard-spread to the analytics contract-type enum.

GET /requests & GET /requests/{id}: Added standard spread contract payloads ("contract": "spread", "spread-type": "time"). Trade and price proposal references populate dynamically once prices are entered.

last-seen-price (trade endpoint): Added a dedicated StandardSpreadLastSeenPrice shape (type: standard-spread, single spread-price). This was needed because standard spreads are traded and quoted as one net price, not per leg — the individual leg prices don't exist yet at trade time, so the existing per-leg SpreadLastSeenPrice shape could not represent what the trader last saw.

Webhooks: The request-traded payload remains unchanged. For standard spreads, the webhook is sent only after enmacc has entered the leg prices.

Standard Spread Pricing: Standard spread prices are calculated as leg1 - leg2. For the broader spread-pricing change, see the separate API Release Notes: Spread Price Calculation Update below.

v2.2 Write Restrictions: Attempting to create or quote a standard spread on v2.2 returns 422 Unprocessable Entity with an explicit error message prompting an upgrade to v2.3.

v2.2 Analytics Restrictions: Requesting analytics for standard spreads via v2.2 endpoints returns 422 Unprocessable Entity.

v2.2 Read Compatibility: Endpoint fetch mapping on v2.2 has been updated to allow reading standard spread payload definitions (quotes, ICOs, price proposals, and RFQ details) without schema validation errors.

Calculation logic: The legs array determines the order: index 0 is Leg 1 and index 1 is Leg 2. This order remains fixed throughout the RFQ lifecycle, and both counterparties receive the same spread price. For opposite-direction spreads, the calculation is Leg 1 Price - Leg 2 Price, regardless of which leg is bought or sold, replacing Buy Leg Price - Sell Leg Price. Same-direction spreads continue to be calculated as the sum of both leg prices.

Impact on values: The sign is determined by the fixed leg order and whether the legs have opposite or equal directions, not simply by whether Leg 1 is bought or sold. For example, with Leg 1 at 30.00 and Leg 2 at 29.00, both BUY / SELL and SELL / BUY produce +1.00. Same-direction spreads are summed, so both buys or both sells produce +59.00 in this example.

Endpoint impact: This change affects spread-price on v2.0 price-proposal reads, v2.1 quotation reads and writes, and v2.2 quotation, price-proposal, and individual-counteroffer reads and writes. It does not affect individual leg prices (legs[].price), executed deals (/trades), custom-spread analytics, webhook payloads, or single RFQs.

End of Day Prices API: A new documentation section is now available at End of Day Prices, covering authentication, available endpoints, request/response schemas (including all GoO-specific fields), and integration examples.

Add Price Proposals: Users can now add "firm" or "indicative" price proposals to active RFQs through the API. Posting a new price proposal to the endpoint will replace any existing proposals.

Delete Price Proposals: An API endpoint has been introduced to facilitate the deletion of existing price proposals.

Green Grey Swaps can be identified through the new spreadType parameter, now available in the /entender/requests/{id} endpoint. The spreadType parameter provides two values:

To submit quotes for Green Grey Swaps, ensure you provide prices for all three legs. Missing prices will result in an error. Power legs within the swap must be priced consistently—for example, if you quote a Buy GoO price of “6” and a Buy Power price of “90,” then the Sell Power must also be “90.”

New risk endpoints are introduced for better Risk Management experience.

Toggle risk management on or off per commodity, allowing individualized control over risk evaluation within trading processes.

Update detailed risk settings, for each commodity that has risk management on the platform.

New V2.2 endpoints are introduced across all trading API.

A new endpoint is now available for executing trades on entender directly via the API. You can either accept a quote as an RFQ initiator or accept a price proposal as an RFQ recipient.

The API now supports the newly introduced partial trading feature, facilitated primarily by the addition of the "all-or-none" field in relevant endpoints.

The analytics endpoint contains now also the feedback comment that the initiator sends to other participants once the RFQ is closed or traded.

A new endpoint and functionality have been introduced to incorporate enmacc's smart recipient suggestions, whenever they are available.

The load shapes endpoint has been improved and divided into two endpoints, making it easier to access shape details from active requests or traded deals.

Clearing information is now defined per leg, instead of per request.

The 'Quote' attribute now includes a price direction as "bid" or "ask", and 'price-direction' is exposed in the analytics endpoint.

Webhooks now feature updated event names. Please consult the documentation for the new names and their corresponding meanings.

Attribute names have been standardized across various endpoints for clarity. For example, 'id' is now 'request-id' in the /entender/requests endpoints. Similarly, 'id' is 'trade-id' in the /trades endpoints.

Spreads have been restructured, with legs now represented as an array. Additionally, the 'Action' field for spreads now supports same-direction spreads.

Object models have been updated, introducing new models for single and spread RFQs and trades. 'View' has been moved inside the execution object. Additionally, 'spread-id' and 'entender-pre-trade-id' have been replaced with a new object 'pre-trade' in /trades/{id}.

Old entender endpoints are deprecated.

We've removed attributes like spread-id and entender-pre-trade-id, as well as deprecated properties like clearing from relevant endpoints.

Minor update aligning the documentation with the properties already exposed through the API.

Enhanced “/trades” endpoints: The /trades endpoints now accommodate the new commodities, and we’ve added an additional property to capture the ID of the entender request that led to the trade.

Deprecated entender “/quotations” endpoints: The old 2.0 entender quoting endpoints are deprecated. Instead, new 2.1 endpoints are introduced to ensure compatibility with the updated entender trading, handling all the new commodities seamlessly.

Documentation for request creation (POST /entender/requests) has already been updated to support all commodities, however they will only be available for creation at the end of August 2023!

Elcerts have been removed from all endpoints: The offering of elcerts on the enmacc platform has been discontinued and all references to elcerts have been removed from the API.

A new endpoint was created to retrieve concluded entender requests. This replaces the concluded filter for the /entender/requests endpoint! This filter is deprecated and will soon be removed!

New filters available when querying /entender/requests: created-at and concluded-at filters for querying entender RFQs created or concluded within the specified period.

Changes made to reflect an expansion to our clearing capabilities with multiple different exchanges. Most of the clearing related properties have been deprecated and will be removed in the near future.

Changes applied to the documentation: Balancing zone names have been adjusted and new ones added. An additional disclaimer has been added to the entender/{id} endpoint to remove ambiguity regarding "buy/sell" on RFQs.

Major update for enmacc connect API with several new endpoints and data models available to interact with entender via the API.

Announcement of a new version for enmacc connect HTTPS API with a new data model and structure of endpoints. Additionally, specific enmacc HTTPS API V1 endpoints are marked deprecated.