Skip to content

Order types and position effects

Choose an order type for its execution condition, then specify how a fill may change exposure. An order type alone does not determine whether an existing trade will be reduced, closed or accompanied by a new trade.

Entry order types

Type Execution condition SDK convenience method
Market Requests immediate execution, subject to time-in-force, liquidity and other constraints post_market_order()
Limit Requests the specified price or better post_limit_order()
Stop Triggers execution when its price condition is reached; the final price can differ post_stop_order()
Market-if-touched Triggers market execution when its touch condition is met; it is not a limit-price guarantee post_market_if_touched_order()

For precise trigger behavior, price bounds and allowed combinations, use the order reference and OANDA's order definitions. A market order can be rejected or cancelled; it does not guarantee a fill.

Time in force

  • FOK: fill the requested quantity immediately or cancel.
  • IOC: execute the available quantity immediately and cancel the remainder.
  • GTC: remain active until filled or cancelled.
  • GTD: remain active until the specified expiry, unless filled or cancelled first.
  • GFD: an OANDA enum value whose support depends on the specific order schema.

Not every order type supports every enum value. In particular, market order requests use FOK or IOC. For a GTD request, supply an aware gtd_time. The enum reference lists wire values; it does not override an individual model's validation.

Position-fill behavior

OrderPositionFill controls whether fills may open or reduce trades. Its values are OPEN_ONLY, REDUCE_ONLY, REDUCE_FIRST and DEFAULT. The effect of DEFAULT depends on the account's hedging configuration. Use an explicit close endpoint when your intent is to close a known trade or position side.

The model interface exposes fields that some convenience methods omit:

from decimal import Decimal

from fivetwenty.models import MarketOrderRequest, OrderPositionFill, TimeInForce

request = MarketOrderRequest(
    instrument="EUR_USD",
    units=Decimal("1"),
    timeInForce=TimeInForce.IOC,
    positionFill=OrderPositionFill.OPEN_ONLY,
)
print(request.model_dump(mode="json", by_alias=True, exclude_none=True))

This constructs a request without sending it. To submit a request model, call client.orders.post_order(account_id, request) from the configured application.

Dependent orders

Take-profit, stop-loss, trailing-stop-loss and guaranteed-stop-loss orders attach to a trade. Request-model *_on_fill fields specify them for a newly opened trade; put_trade_orders() manages them on an existing trade. An entry stop order and a dependent stop-loss order are different schemas and operations.

Guaranteed stops have account-specific availability and restrictions. Ordinary stop-loss placement does not promise that realized loss will equal a chosen price distance. See stop-loss management.

Order state and transactions

The SDK's OrderState values are PENDING, FILLED, TRIGGERED and CANCELLED. They are states, not a mandatory sequence every order follows. Rejections are reported through errors and transaction types rather than an OrderState.REJECTED.

A creation response may already include a fill or cancellation. Replacing a pending order creates a new order ID. Store transaction relationships and re-read the target when cancellation or replacement races with execution.

See order management for a workflow and advanced-order tutorials for focused exercises.