An API for CFD products needs contract metadata as well as prices, because similar names can describe different broker instruments.
Capture the reference asset, quotation currency, trading session and price precision for each contract. Keep a stable internal identifier when a marketing label or server suffix changes so consumers do not accidentally join unrelated histories.
Choose snapshots for occasional valuation and streaming for continuously updated screens. If both are used, define how a client joins the initial snapshot to subsequent updates without presenting an older observation after a newer one.
Bring the proposed instrument list, source documentation and consumer workflow to a technical discussion. The agreed integration specification defines coverage, fields, usage permissions and acceptance tests.
| Instrument scope | Identify the exact underlying, source identifier, quote currency and intended use. |
|---|---|
| Consumer workflow | List trading platforms, charts, risk tools and applications that need the output. |
| Delivery contract | Agree protocol, quote fields, timestamps, source status and recovery behaviour. |
| Production review | Confirm source rights, integration ownership, test evidence and commercial scope. |
For your instrument universe, define who consumes the prices and what each system needs to reconstruct a usable quote. An application dashboard, broker platform and historical process can require different delivery rules even when they share one normalized instrument model.
{
"type": "quote",
"symbol": "EURUSD",
"bid": "1.10000",
"ask": "1.10010",
"source_time": "2026-10-18T12:00:00.000Z",
"received_at": "2026-10-18T12:00:00.012Z",
"source_id": "example-source",
"status": "illustrative"
}Illustrative engineering example, not live prices or a published API contract. Confirm field names and delivery rules during integration.