What to Do When a Broker API Rejects an Order

A trading application can generate a technically valid order request and still receive a rejection from the broker API. The rejection may relate to order parameters, account conditions, instrument rules, authentication, limits or a temporary service problem.

For developers and trading businesses, the important question is not simply why an order was rejected. The system must also decide what to record, what the user should see, whether another attempt is safe and when the issue needs investigation. Treating every rejection as a generic error can create confusion and, in some cases, unsafe retry behaviour.

What an Order Rejection Means

An order rejection means the broker or trading venue did not accept the submitted order for execution. The exact reason depends on the API and the trading environment.

A rejection is different from a network timeout. With a clear rejection response, the application has received a response indicating that the order was not accepted. With a timeout or connection failure, the application may not know whether the broker received or processed the request.

This distinction is important because the correct recovery action can be completely different.

Common Rejection Categories

Order rejection reasons can generally be grouped into categories such as:

• Invalid order parameters: quantity, price, order type or other fields do not meet the API requirements.
• Instrument or market restrictions: the selected instrument, segment, contract or order type may not be available under the requested conditions.
• Account-related restrictions: the account may not have the required permissions, available funds or other conditions for the order.
• Trading limits: quantity, price, position or other limits may prevent acceptance.
• Authentication or authorisation issues: credentials, tokens or permissions may be invalid or expired.
• Temporary broker or service errors: the API may be unavailable or return a temporary processing error.

The application should preserve the broker's original error code and message where appropriate rather than replacing everything with a generic “Order failed”.

Why Rejection Classification Matters

Different failures require different actions. A system that retries every rejected order can turn one failed request into several requests.

For example, suppose a strategy sends an order with an invalid quantity. Retrying the same request will normally not fix the underlying problem. The software should record the rejection, show a useful message and stop that attempt.

A temporary service problem is different. Depending on the broker's documented behaviour, a controlled retry may be reasonable for some technical failures.

Separate Business Errors from Technical Errors

A useful design is to classify the response before deciding what to do.

1. Business or validation rejection: The request does not satisfy a trading or account rule.
2. Authentication failure: The application cannot make an authorised request.
3. Temporary technical failure: The service may be unavailable or unable to process the request at that moment.
4. Unknown outcome: The application cannot establish whether the broker received or processed the request.

The fourth category deserves special attention. It should not automatically be treated as a simple rejection.

Log the Rejection With Enough Context

Good logging makes a rejected order diagnosable without requiring someone to reconstruct the entire event manually.

At minimum, a trading application should consider recording:

• Internal order ID or client order ID
• Strategy or user identifier
• Instrument and exchange segment where applicable
• Order side
• Requested quantity
• Order type
• Price-related fields where applicable
• Timestamp
• Broker request identifier, if provided
• Broker response code
• Broker response message
• Application error classification
• Current strategy state
• Retry decision
• Final order status

Do not log sensitive credentials, access tokens or secrets merely because they were available during the API request.

Keep Request and Response Records Together

The request that caused the rejection should be traceable to the response. A unique internal order or correlation ID helps connect application logs, broker responses and user-visible events.

For example:

Internal Order ID: ORD-2026-00125

Requested: BUY 100 units

Broker Response: Rejected

Broker Code: BROKER_CODE

Classification: Validation rejection

Retry: No

User Status: Order rejected

The actual broker code and message should come from the broker's response, not from invented application values.

What the User Should See

A user does not need a raw API response dumped onto the screen. At the same time, hiding the reason completely makes troubleshooting difficult.

A useful user message should explain three things:

1. What happened: The order was rejected.
2. Why, when known: Give a readable explanation based on the broker response.
3. What happens next: Explain whether the application will retry, stop or require user action.

For example:

Order rejected: Quantity is outside the allowed range. No automatic retry was made.

This is more useful than:

Error 400.

For technical support users, the interface can provide an order reference that can be matched with detailed server logs.

Retry Rules Must Be Conservative

Retries are one of the most important parts of order error handling.

A retry should not be based only on the fact that an API call failed. The software needs to determine whether retrying is safe and whether the outcome of the previous request is known.

When Not to Retry

Automatic retry is generally inappropriate for a clearly identified validation or business rejection that will remain unchanged.

Examples include:

• Invalid quantity
• Invalid order parameters
• Unsupported order type
• Missing required field
• Insufficient permissions
• A known account restriction

Sending the same invalid request repeatedly adds load and does not correct the problem.

When a Retry May Be Considered

For some temporary technical failures, a controlled retry may be possible if the broker's API documentation and the application's order model support it.

A robust design should consider:

• A maximum retry count
• A delay between attempts
• An idempotent or uniquely identifiable order request where supported
• Reconciliation after uncertain outcomes
• Clear logging of every attempt
• A final state that prevents uncontrolled retry loops

The key principle is retry the operation only when the system can reason about its safety.

Unknown Outcomes Need Reconciliation

Consider a different scenario. The application sends an order, but the network connection breaks before the response reaches the application.

The software now does not know whether the broker rejected the request, accepted it, or processed it partially. Treating this as “definitely rejected” can be dangerous.

Instead, the application should use the broker's supported order-status or order-history mechanisms to reconcile the state.

A Safer Recovery Flow

A simplified flow can be:

1. Create an internal order record.
2. Send the order request.
3. Receive a clear rejection and mark the order rejected.
4. If the response is unavailable or ambiguous, mark the request as outcome unknown.
5. Query the broker for the relevant order status where supported.
6. Match the broker result with the internal order or client order ID.
7. Update the local state.
8. Only consider a new order if the original outcome is understood and the strategy rules permit it.

This prevents the application from creating a second order simply because the first response was lost.

Design a Clear Order State Model

A trading system should not rely on one boolean such as `orderSuccess = true`.

It is better to represent meaningful states such as:

• Created
• Submitted
• Accepted
• Rejected
• Partially filled
• Filled
• Cancelled
• Outcome unknown
• Reconciled

The exact states depend on the broker and application requirements, but the principle is the same: the software should know what it knows and explicitly represent what it does not know.

Common Implementation Mistakes

Treating Every Error as Retryable

This can create repeated requests for a permanently invalid order. Retry decisions should be based on error classification.

Ignoring Broker Error Codes

A human-readable message is useful, but structured broker codes are often important for application logic. Preserve them when available.

Losing the Original Request

Without the original quantity, price, order type and identifiers, support teams may struggle to understand why the broker rejected the request.

Marking Timeouts as Rejections

A timeout means the application did not receive a response. It does not necessarily prove that the broker rejected the order.

Allowing Infinite Retries

An automated trading system should have explicit retry limits and a controlled terminal state.

Build Rejection Handling as Part of the Trading Architecture

Order rejection handling should not be added only after the first production failure. It belongs in the design of the order-management layer.

A practical architecture can separate:

• Order generation: strategy decides what it wants to trade.
• Validation: application checks known requirements before submission.
• Broker adapter: converts the internal order into the broker API format.
• Submission: sends the request and records the attempt.
• Response classification: identifies rejection, acceptance or uncertain outcome.
• Reconciliation: checks broker state when necessary.
• User notification: communicates the result clearly.
• Audit logging: preserves the complete lifecycle.

This separation makes it easier to change broker integrations without rewriting the strategy itself.

Testing Order Rejection Scenarios

Testing should include more than successful order placement.

Useful scenarios include:

• Invalid quantity
• Invalid price
• Missing authentication
• Expired authentication
• Unsupported order parameters
• Insufficient account conditions
• Temporary API failure
• Network timeout after submission
• Duplicate submission attempt
• Delayed broker response
• Partial fill followed by another status update

The goal is to verify that each situation reaches the correct state and does not trigger an unintended order.

Why Rejection Handling Matters for Trading Software

A trading application is not complete merely because it can send an order. It must also handle the cases where the broker says no, the network says nothing, or the response arrives later than expected.

Reliable order management requires clear states, structured logs, conservative retries and reconciliation of uncertain outcomes. These engineering details are especially important when automated strategies can generate orders without a person manually reviewing every request.

Suyotech Solutions approaches trading software as a software engineering problem, including strategy logic, broker API integration, order management, logging and operational handling according to the project's requirements.

Conclusion

Broker API order rejections are normal failure scenarios that should be designed for, not treated as unexpected exceptions. Classifying rejection reasons, preserving useful logs, giving clear user messages and applying controlled retry rules can make an automated trading application easier to operate and troubleshoot.

Most importantly, a timeout or unknown response should not be assumed to mean that no order exists. Reconciliation is essential whenever the outcome of a request is uncertain.

For trading software, broker API integration or custom order-management development, contact Suyotech Solutions to discuss your software requirements.

Trading software and automation involve technical and market risks. Backtests and automated systems cannot guarantee future trading results or profits.