The CuteMarkets options and stocks APIs have a published OpenAPI 3.1 specification:
Use it with API clients, code generators, docs tools, or agent frameworks that can ingest OpenAPI.
Authentication
The spec uses a bearer security scheme for API keys:
Authorization: Bearer YOUR_API_KEY
Scope
The specification covers the documented REST market-data surface:
- option chains and contract snapshots
- contract reference lookups
- options trades and quotes
- stock snapshots, movers, and ticker reference
- stock trades and quotes
- aggregate bars, previous-day bars, and open-close snapshots
- SMA, EMA, MACD, and RSI indicators
- ticker search and expiration lookup
The WebSocket gateway is documented separately in WebSockets, because OpenAPI does not model the live streaming protocol.
Base URLs
Production:
https://api.cutemarkets.com
Local development:
http://localhost:8000
Related docs
Code generation checklist
The OpenAPI file is useful for typed clients, smoke tests, and agent tooling, but generated clients still need product-specific configuration. Keep the base URL, bearer token injection, retry policy, and pagination handling outside generated endpoint methods so they can be changed without regenerating the entire client.
| Concern | Recommended handling |
|---|---|
| Authentication | Inject Authorization: Bearer YOUR_API_KEY through one client middleware. |
| Pagination | Treat next_url as an opaque signed URL. Do not rebuild cursor strings. |
| Products | Keep Stocks API and Options API keys separate in configuration. |
| Errors | Model the standard status: "ERROR" envelope and preserve request_id. |
| Streaming | Use the WebSocket docs directly; the REST OpenAPI spec does not describe streaming subscriptions. |
Agent and CI usage
For CI, use the specification to validate request shapes and response envelopes before hitting live endpoints. For coding agents, pair the OpenAPI file with Agents.md, because the agent doc explains product intent, endpoint order, and common workflow boundaries that a schema alone cannot express.
What the schema does not decide
The OpenAPI schema describes endpoint paths, parameters, response shapes, and authentication mechanics. It does not decide which endpoint should be called first in a workflow. For example, an options application should usually discover expirations before requesting a chain, then select a contract before requesting historical quotes or trades. A generated client can call every endpoint, but the application still needs product logic.
The schema also does not replace plan checks. A route can be valid while the current key lacks the product scope, quote entitlement, or historical lookback required by the request. Generated clients should expose the full error envelope so callers can distinguish bad parameters from missing entitlement.
Recommended client structure
Keep generated endpoint methods small and deterministic. Wrap them with a hand-written client layer that owns authentication, product key selection, retries, logging, and pagination. That layer should attach the correct Options or Stocks API key, preserve the request_id from every response, and treat next_url as an opaque URL instead of rebuilding cursor parameters.
For teams using agentic coding tools, check the generated code into version control and regenerate it deliberately when the OpenAPI file changes. Do not let every agent run a different generator configuration. Stable generated clients make documentation examples, CI tests, and application code easier to compare.