Locate and manage Flex Queries in Client Portal
Flex Query setup begins in the authenticated Client Portal, not in TWS, IB Gateway, or an ib_async connection. This page deliberately uses stable destinations and capabilities instead of depending on the exact appearance of a button or card.
Open the Flex Queries workspace
IBKR's current public Client Portal guide documents two navigation paths:
- Open Performance & Reports, then Flex Queries.
- If the portal presents its compact menu, open Menu, then Reporting, then Flex Queries.
Treat Flex Queries as the stable destination. Portal grouping, capitalization, icons, and responsive layout can change without changing the reporting workflow.
The official Flex Queries guide describes this workspace as the place to:
- run a saved Flex Query;
- create an Activity or Trade Confirmation Flex Query;
- view, create, edit, and delete saved queries;
- configure delivery settings; and
- open Flex Web Service configuration.
For account reporting and reconciliation, create or select an Activity Flex Query. A Trade Confirmation Flex Query has a different freshness and data boundary; choosing one is not an interchangeable UI detail.
Identify the saved query without depending on its screen position
Give each saved query a descriptive, purpose-specific name. After saving, record the identifier for that exact query in application configuration as query_id.
The current official Client Portal configuration guide documents the identifier location:
- Open Flex Queries.
- Select the Info icon to the left of the saved query.
- Capture the Query ID shown at the top of the information popover.
- Confirm it belongs to the intended named query and report family.
- Store it as sensitive configuration.
- Record a non-secret template revision separately so consumers can detect intentional schema changes.
Pinned ib_async 2.1.0 accepts that value as queryId and sends it as the q query parameter when FlexReport.download starts a report request. That is version-pinned library behavior, not official protocol authority. The request-and-polling guide will establish the current official parameter semantics before recommending an HTTP implementation.
Saved query configurations are username-specific. For linked accounts, query visibility also depends on the selected account set: search with the same account selection used when the query was created. The token is visible from the master account and can retrieve linked-account data only according to the accounts included in the saved query. If Client Portal no longer presents an unambiguous Query ID, stop and verify the current UI through a controlled, dated observation; never infer it from a name or another environment.
Keep configuration ownership explicit
| Item | Owner | Safe repository representation |
|---|---|---|
| Saved-query name | Reporting administrator | A neutral placeholder such as DAILY_ACTIVITY_XML |
| Query identifier | Secret/configuration owner | Placeholder only, such as YOUR_QUERY_ID |
| Selected sections and fields | Reporting administrator and data consumer | A versioned field manifest without account data |
| Expected schema revision | Data consumer | A non-secret revision or configuration hash |
| Service token | Secret owner | Environment-variable name only, never the value |
Changing the selected fields, period, ordering, or output format changes what downstream consumers receive. Identifying a saved query is therefore not enough: bind its identifier to an expected template revision and validate the returned XML before ingestion.
Official documentation versus manual verification
| Setup detail | Evidence status |
|---|---|
| Navigation to the Flex Queries workspace | Officially documented |
| Ability to create, run, edit, delete, and configure saved queries | Officially documented |
A saved template controls fields, time period, field order, and TEXT or XML output | Officially documented |
| Query ID in the information popover opened from the saved query's left-side Info icon | Officially documented |
| Username-specific query ownership and linked-account selection visibility | Officially documented |
| Current visual styling or responsive position of the documented Info control | Requires a dated authenticated observation |
| Which account, model, and detail-level selectors appear for a particular account role | Requires evidence for that role and portal version |
Authenticated HTML, screenshots, tokens, real query identifiers, account identifiers, and downloaded statements remain private and must not be committed. A later verified observation belongs under the controlled behavior program; it should record the date, account role, portal version if visible, and redacted result without publishing authenticated material.
Next, design the saved Flex Query as a versioned consumer contract: sections, fields, scope, period, formats, and XML shape must change deliberately.