Requests and responses
Every operation and workflow page documents its complete parameter tree, recursive response shape, copyable example, limitations, and exceptions. Start from the relevant operation or workflow, not from a global model list.
Convenience imports
The following frequently used dealing and discovery types are available directly from
ig_trading_lib:
| Type | Role | Primary reference |
|---|---|---|
CreatePositionRequest |
Open-position request body. | positions.create |
AmendPositionRequest |
Position-amendment request body. | positions.amend |
ClosePositionRequest |
Position-close request body. | positions.close |
CreateWorkingOrderRequest |
Working-order request body. | working_orders.create |
AmendWorkingOrderRequest |
Working-order amendment body. | working_orders.amend |
DealConfirmationResponse |
Confirmed dealing result. | confirmations.get |
MarketSearchResponse |
Market-search result. | markets.search |
MarketGetResponse |
Detailed market result. | markets.get |
from ig_trading_lib import CreatePositionRequest
request = CreatePositionRequest(
epic="CS.D.EURUSD.CFD.IP",
direction="BUY",
size=1,
order_type="MARKET",
currency_code="GBP",
)
confirmation = ig.workflows.positions.open_and_confirm(request)
Model behaviour
- Request models validate declared fields before transport.
- Response models normalise documented provider fields to
snake_case. - Provider-added response fields remain available for forward compatibility.
- Invalid request data or incompatible response data raises
pydantic.ValidationError. - Method pages are authoritative for defaults, constraints, nested shapes, and examples.