Make your first Developer API request

Start with the public developer workflow

The Developer API gives programs read-only access to eligible market data and analytics. REST routes live under /v1, developer WebSockets under /v1/ws and the MCP endpoint at /mcp. These use developer keys and the account's API permissions, rather than the browser cookie that signs you into the terminal. API Developer and API Pro are separate from Options, Futures and Bundle terminal plans. Before writing a data client, open Developers → Overview and confirm the API state you intend to use. No API workflow places orders.

Create a project and its first key

Open Developers → API keys, create a project with a recognizable name and create a key in that project. Copy the full om_ value while the creation dialog shows it; only its hash is retained by the server, so you cannot recover the secret later from its prefix. Store it securely for the program that needs it. The optional Use this key in the API reference on this device keeps a tab-scoped browser copy for the reference tools, which is not a durable backup for your integration.

Authenticate a small account request

Use the base URL for the running environment and request GET /v1/account. Send Authorization: Bearer followed by the full key, or the documented X-API-Key header. Do not put the secret in a query parameter or share it in a URL. Inspect the returned account API state before requesting a large market range. A valid key proves authentication, while subscription, dataset and history permission are checked separately. GET /v1/status and GET /v1/openapi.json are public diagnostic and specification routes that do not demonstrate authenticated account access.

1. Create a project and save the one-time full key.
2. Send GET /v1/account using the key in an authentication header.
3. Read the returned API access before choosing a market-data endpoint.

Choose one narrow catalog query

Open API Reference and select an endpoint that matches your data question. Read its required parameters, supported symbols, session values and response schema. For example, /v1/options/flow uses underlying_symbol and supports documented tape filters; an exact option-contract route needs root, expiration, strike and right instead. Begin with a small result limit and narrow selection so the response is easy to inspect. A familiar market label is not always the route's exact identifier: SPX and SPXW can distinguish different option roots or family behavior.

Read data, metadata and pagination together

A successful response contains data plus metadata describing its request, as-of time, source, delay and coverage. Missing values remain null rather than being assumed to be zero. Follow the documented pagination cursor until the selection is exhausted, even if an intermediate filtered page is short or empty. Check whether coverage is complete, partial, truncated or still pending. A 200 status establishes that the request succeeded under its contract; it does not mean every session observation exists or that a delayed source is now real-time.

Build around shared limits

All keys and projects for an account share 250 requests per rolling minute and a 30-per-second burst limit, with additional concurrency bounds. There are no usage credits. Read X-RateLimit headers and honor Retry-After or retry_after_ms when returned. Keep retries bounded, avoid re-requesting identical historical selections unnecessarily and handle a service-unavailable response according to its code. Creating extra keys does not add capacity. REST, MCP and developer stream access share the same owner and plan boundaries even though their transports and specific connection rules differ.

Confirm a working result and keep evidence

A useful first result is a valid authenticated account read followed by a small eligible market query whose metadata you understand. Inspect Request logs and Usage for the matching request if it fails. A 400 usually needs parameter correction, 401 needs authentication investigation and 403 can concern API subscription, dataset or history access. Preserve the request ID, route, safe parameters and relevant coverage for support. Never paste the full key into the ticket. A configured hostname or example response is not evidence that your particular live dataset has completed provider acceptance.