Identify the failing stage before changing settings: authentication, market data, order routing or the displayed result. Record the exact message and timestamp, then follow the matching checks below. A successful login does not establish working market data or accepted orders.
Educational software guidance. Trading involves risk. Read the financial and information disclaimers.
Choose the symptom
| What you observe | Start with | Evidence to retain |
|---|---|---|
| Login is rejected | Credentials, provider-specified System and account activation | Exact login response |
| Login works but quotes do not | Data connection, instrument, entitlement and product schedule | Affected symbols and timestamps |
| Quotes update but an order fails | Order response, account permission and risk rules | Request and response sequence |
| Connection repeatedly drops | Session configuration, network and platform load | Disconnect times and component status |
| Display differs from expected result | Account, expiry, filters, fills and timezone | Comparable records from each layer |
Login or authentication problem
Use the Rithmic credentials issued by the provider and its exact System name. Evaluation, funded and demo labels are not enough to choose a System. Apex's setup guide provides Apex-specific instructions; other providers can differ.
Check for surrounding spaces and whether the account is active. If credentials or account mapping are rejected after those checks, contact the issuing provider. Repeated guesses do not diagnose an FCM or IB association.
Connected but no quotes
Check whether the price connection is active, whether the correct contract is selected, and whether your subscription includes the required exchange and data level. Use the provider's agreement process and accurate subscriber classification. Completed agreements alone do not prove the entitlement is active.
Quantower's Rithmic troubleshooting documentation describes platform-specific data checks. Use the market-data guide for a detailed decision table.
Order rejected or apparently missing
Read the exact response and inspect working orders and fills before retrying. A risk rejection, invalid contract and transport timeout are different problems. A restriction may need provider action and may not reset at the next session.
Use order-rejection checks and order history to build the event record. Do not create another trade solely to test a connection whose account state is uncertain.
Repeated disconnections
Compare the timing with another login, a network interruption, platform load or an announced maintenance window. Timing is a clue, not a root-cause finding. Use the exact connector's direct or plugin instructions; there is no universal one-session rule across all Rithmic interfaces.
The Sierra Chart Rithmic documentation illustrates why connector-specific requirements matter. Do not close a platform that manages local exits without first understanding its role and current orders.
Different prices, quantities or P&L
Match the account, expiry, price basis, session, timezone and data feed. For quantity differences, compare executions and remaining orders. For P&L, distinguish realized and open results and determine whether commissions are included. Similar-looking charts can use different contracts or session settings.
Escalate with a useful record
Include the platform version, provider, System/Gateway, symptom, exact time, relevant settings and redacted response. State which checks succeeded and failed. Keep private account identifiers within the provider's approved support channel.
Common questions
Is there a universal reset procedure?
No. Restarting every platform can interrupt local order management and erase useful context. Diagnose the failing stage and follow the platform's recovery procedure.
Does a working R Trader Pro login prove another platform is at fault?
No. The applications can use different interfaces, entitlements and sessions. It narrows the investigation but does not identify the cause by itself.
Should I select Non-Professional to fix data access?
Only if you meet the applicable criteria. Subscriber classification is a factual declaration, not a troubleshooting switch.
Does this decision table need an error screenshot for every branch?
No. It is a diagnostic reference, not a catalogue of reproduced errors. An authentic screenshot helps when reporting your particular error; no error was fabricated for this guide.