Understand API plans versus terminal access

Treat terminal and API access as separate products

Options, Futures and Bundle are terminal subscriptions for the application's market-analysis tools. API Developer and API Pro are separately billed products for programmatic access through the public Developer API. Buying a terminal plan does not automatically grant API access, and an API subscription does not automatically unlock terminal tools. Legacy Terminal Pro or Terminal Elite naming does not change that separation. When diagnosing access, identify whether the failing operation is a terminal page or a developer-key request before deciding which subscription state to inspect.

Find the API subscription controls

Open Billing and review its API add-on section, which is billed separately from the terminal plan. Read the current offered API plan, amount and available action rather than assuming a card from another product applies. Developers → Overview provides the account's API state and limits, while Billing is the place to review subscription changes. A generated key belongs to an account and project, but its existence alone does not prove that the account has an active API plan or permission for every market dataset.

Verify programmatic access with the account endpoint

Create or select a valid developer key and request GET /v1/account in the running environment. Inspect the returned API plan, dataset permissions and related state before trying a large market query. This separates authentication from product access: a key can be recognized while the account still needs an API subscription. Use the API Reference for a particular route's plan, history and dataset requirements. Do not infer permission from the fact that the corresponding chart is visible in a terminal session authenticated through browser cookies.

1. Review API products in Billing's separate add-on section.
2. Inspect Developers → Overview for the current API state.
3. Use a developer key with GET /v1/account before diagnosing a market-data request.

Share one allowance across keys and protocols

All keys and projects on an account share 250 requests per rolling minute and a 30-per-second burst limit, together with applicable concurrency bounds. There are no usage credits to purchase, consume or replenish. Creating a second project or rotating a key does not reset the account's allowance. REST and MCP use the shared validation and access model, and developer streams retain their own documented connection and plan limits. A terminal subscription does not add another pool of developer requests to the same account.

Check streaming, history and dataset boundaries

API plan permission is one layer of access. Individual routes can require a particular dataset, supported history window or streaming entitlement. A plan that permits one query does not establish complete retained history for every instrument. Likewise, a valid REST response does not guarantee a developer WebSocket event type is included. Read the actual endpoint and stream contract in Developers, then inspect error codes and response coverage. The underlying API remains read-only: neither an API plan nor an MCP connection enables order placement.

Manage each subscription deliberately

When upgrading, changing or canceling, verify which product's action you are using. A terminal plan change can leave the API subscription unchanged, and managing the API plan does not establish the terminal's next renewal state. Read the provider preview or management confirmation and return to the appropriate Billing entry afterward. If an account uses multiple email identities, inspect the signed-in account before assuming a subscription transferred between them. Subscription ownership, developer projects and saved terminal resources follow their account, not a display name entered in Settings.

Diagnose a mismatch without buying blindly

For API access failure, collect the route, safe parameters, error code, request ID and returned API state. For terminal restriction, include the page, dataset, session and Billing status. A 401 developer response points toward authentication, while a 403 can concern subscription, dataset or history access. Missing source capture is a separate problem from either one. A configured checkout or catalog entry is not proof of a completed payment or verified live dataset. Ask support to investigate the concrete state before purchasing an unrelated product to try to remove the error.