Developer platform
Explore the Forecast, Data, and Chat APIs, generated reference, model catalog, API keys, request history, and copyable code.
Open the developer console- Status
- Limited preview
- Access
- Signed-in console · API keys require access
- Reading time
- 11 minutes
- Reviewed
- Aug 29, 2026
- Maintained by
- Developer platform
The developer console exposes the same source-aware grid systems used by the product through three API families. Forecast returns probabilistic model paths, Data queries the catalog through a bounded contract, and Chat runs the grid agent. Every signed-in account can inspect the console, reference, models, and playgrounds.
A playground request uses the signed-in browser session and renders the response as the form that best explains it: chart, table, answer, or raw JSON. API keys are bearer credentials for calling the service from another system and remain access-controlled separately from the console itself.
On this page · 4 sections
Choose the API for the job
Forecast API
Request a supported model product and horizon to receive a probabilistic forecast path with quantiles and model metadata. Use the model catalog to confirm the product, input contract, horizon, cadence, and output shape before integrating it.
Data API
Describe a source-aware grid question and receive the bounded query result beside the compiled SQL and dataset context. Use the catalog contract to preserve market scope, time semantics, units, and table lineage.
Chat API
Send a market-scoped question to the grid agent and receive the same source-backed answer path available in the product. Keep the active market explicit rather than asking a downstream client to infer it from the prompt.
Use the interactive playgrounds
Make a request before writing code
Choose a product or fill the request form, run it with the signed-in session, and inspect the returned status, timing, headers, and body. The visible chart or table is paired with the raw response so the presentation never replaces the contract.
Copy the request in your language
After a successful request, copy the equivalent cURL, Python, JavaScript, or PHP example. Replace the console session with an authorized API key only when moving the call into another system.
Read the generated reference
Check the contract at integration time
Use the reference for paths, methods, authentication, parameter constraints, request bodies, response schemas, and error shapes. Use the model catalog for model-specific semantics that do not belong in a generic endpoint definition.
Preserve the returned metadata
Keep model identity, forecast vintage, horizon, market, units, data-source lineage, and request identifiers with downstream results. They are part of the meaning and the debugging path, not decorative response fields.
Manage keys, usage, and requests
Create an API key only when access is enabled
The console is open to signed-in accounts; API-key creation is granted separately. Treat a key as a bearer credential, copy it at creation, store it in a secret manager, and revoke it when the integration or operator no longer needs access.
Use request history to reproduce failures
Requests records the API family, path, status, latency, and request identifier. Match that entry with client logs before changing the payload, and use Usage to understand volume across the current account.
Choose MCP for an AI client
Use MCP when ChatGPT, Claude, Cursor, Codex, or another compatible client should discover typed grid tools through OAuth. Use an API key when code you operate needs a direct HTTP contract.
Did this guide get you unstuck?
One click is enough. No message or account required.