Fixed-income identity first

Bond option API

Distinguish cash-bond and bond-futures option data, then preserve the security terms, underlying relationships and units your analysis needs.

Bond and rate option API conventions in rainbow fintech typography, branded OptionAPI.com.
Editorial illustration. Figures in artwork are not live quotes.

Choose the product family explicitly

An option on a cash bond is not the same record as an option on a bond future or a rate-related contract. Start with a product-family field and a precise underlying identifier. CME’s Treasury market overview separates its futures, options and cash markets; that distinction is a useful starting point for a taxonomy, not proof that one feed supplies all three.

Keep security context near the price

For a cash-security reference, identify the actual bond and the terms needed for your intended analysis. Preserve the source’s quotation convention and any normalization. Do not place a yield, a price and a modeled sensitivity under one heading simply because each is a number.

Resolve a futures layer when it exists

For an option on a bond future, retain the exact future rather than a generic Treasury label. Its lifecycle and conventions belong in linked records. An option expiry should not erase the underlying contract from your archive, and a continuous research series should not replace that identity.

Make model inputs inspectable

Store curve versions, valuation dates, convention identifiers and output units when your application calculates analytics. Separate those calculations from provider observations. The full guide explains how this convention-first approach extends to rate options without pretending that one formula covers every fixed-income product.

Read the record.
Build with clarity.

Go from a market label to a field you can explain. Start with the guides, then inspect the local JSON examples.