API Access

WebSocket and REST testing for volatility surfaces.

Derivasys can make the live surface API available to approved testers upon request. The API is designed around real-time WebSocket streams for live dashboards and REST endpoints for current-state checks, integration tests, and downstream research workflows.

Request access Read dashboard guide

Protocols

WebSocket streams for snapshots and patches; REST endpoints for latest surfaces, smiles, diagnostics, and fixed-tenor rows.

Coverage

BTC and ETH are primary live surfaces. Additional currency feeds are being tested before wider availability.

Access

Testing is request based. Production keys, rate limits, and endpoint URLs are issued directly to approved consumers.

WebSocket stream

The streaming API bootstraps consumers with a full surface snapshot, then sends compact patches as quotes, fits, risk metrics, and fixed-tenor rows change. The browser dashboard uses this same contract for live market monitoring.

svi_surface_snapshot and svi_surface_patch for calibrated surface state.
smile_levels_snapshot and patch messages for bid, ask, trade, and venue-level quote overlays.
svi_tenor_snapshot and patches for fixed-tenor term-structure outputs.
Fit-status, risk-reversal, fly, and diagnostic messages around each calibration cycle.

REST current-state endpoints

REST access is intended for test harnesses and systems that need latest state without maintaining a streaming session. Endpoint names can vary by deployment, but the resource boundary is stable.

/surface/latest for the latest fitted surface snapshot.
/smiles/latest for current smile levels and venue overlays.
/tenors/latest for fixed-tenor rows.
/diagnostics/latest for fit quality, through-fit checks, and risk summaries.

Payload expectations

Payloads are JSON and include the active currency where available. Consumers should treat snapshots as authoritative bootstrap state and patches as sparse updates.

{
  "type": "svi_surface_snapshot",
  "schemaVersion": 1,
  "ccy": "BTC",
  "smiles": [{
    "expiry": 1778990400000,
    "label": "17MAY26",
    "x_axis": { "kind": "log_moneyness", "values": [-0.3, 0, 0.3] },
    "vol": [42.1, 34.8, 38.6],
    "risk_reversals": { "RR25": -5.57 },
    "flies": { "FLY25": 1.37 }
  }]
}

Dashboard diagnostics exposed through the API

The same diagnostics shown in the dashboard can be published for testing: through-fit cells, skew and fly term structures, fit error state, active smile count, and fixed-tenor rows.

Derivasys market diagnostics showing through-fit checks, risk reversals, and fly term structures — The API boundary mirrors the live dashboard state so testers can compare WebSocket and REST outputs against visible diagnostics.

Historical API changes

The public API is currently available for approved testing. These entries describe the client-facing contract changes reflected in the dashboard and documentation.

May 16, 2026: Added request-based WebSocket and REST API testing documentation, including current-state REST resource families.
May 16, 2026: Documented fixed-tenor outputs through svi_tenor_snapshot, tenor patches, and REST-style /tenors/latest access.
May 16, 2026: Added multi-currency testing language for BTC, ETH, and additional currencies under review.
May 16, 2026: Added dashboard consumer support for smile_levels_snapshot_batch messages.
May 16, 2026: Added dashboard consumer handling for currency-selection messages and outgoing select_currency requests.
May 16, 2026: Broadened accepted fly and butterfly payload aliases, including fly_values, butterfly_values, bf, and rr_fly.
May 16, 2026: Broadened accepted fly node payload aliases, including fly_nodes, butterfly_nodes, and camelCase node-point variants.
May 16, 2026: Restored fly diagnostics when scalar FLYxx values are absent by deriving them from matching put, call, and ATM node vols.

Broader product and documentation changes are tracked in the Derivasys changelog.

Requesting access

Email info@derivasys.com with the intended use case, currency scope, preferred protocol, and whether fixed-tenor outputs are required. Test access can then be configured with the appropriate endpoint, key, and usage expectations.