> ## Documentation Index
> Fetch the complete documentation index at: https://api.alphainsider.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Trading

> Convert strategy values into dollars and quantities, size orders, and understand fees and execution.

##### Calculation map

Read this guide before displaying normalized strategy data or sizing a fixed order. The formulas cover caller-side display and request preparation. Use the API's returned multiplier, strategy value, order capacities, and trade results; AlphaInsider calculates those values. Use the exact field locations in the linked operation; the display formulas also apply to corresponding WebSocket and timeline values.

| Task | Read first | Relevant operations |
| - | - | - |
| Resolve the right user's scale | [Multiplier context](https://api.alphainsider.com/resources/trading.md#multiplier-context), [get a multiplier](https://api.alphainsider.com/resources/trading.md#get-a-multiplier) | `getStrategySubscriptions`, `getStrategyCalculation`, `updateStrategyCalculation` |
| Display a portfolio, cash, or quantity | [Display values](https://api.alphainsider.com/resources/trading.md#display-values), [position valuation](https://api.alphainsider.com/resources/trading.md#position-valuation) | `getStrategyValues`, `getPositions` |
| Convert shares or dollars into an order | [Fixed-order inputs](https://api.alphainsider.com/resources/trading.md#fixed-order-inputs) | `newOrder` |
| Check normalized buying/selling capacity | [Order capacity and reserves](https://api.alphainsider.com/resources/trading.md#order-capacity-and-reserves), [fees and exact order sizes](https://api.alphainsider.com/resources/trading.md#fees-and-exact-order-sizes) | `getMaxOrderSize`, `newOrder` |
| Show performance or returns | [Performance and baselines](https://api.alphainsider.com/resources/trading.md#performance-and-baselines) | `getStrategyPerformance`, `getStrategyValues` |
| Show long/short value, exposure, or profit | [Position valuation](https://api.alphainsider.com/resources/trading.md#position-valuation), [position gain/loss](https://api.alphainsider.com/resources/trading.md#position-gain-and-loss) | `getPositions` |
| Show orders or historical trade markers | [Orders and timelines](https://api.alphainsider.com/resources/trading.md#orders-and-timelines) | `getOrders`, `getTimelines`, `getStrategyTimelines` |
| Handle real broker values | [Unscaled values](https://api.alphainsider.com/resources/trading.md#unscaled-values), [bot monitoring](https://api.alphainsider.com/resources/bots.md#monitoring) | `getBotInfo`, `getBotPerformance` |
| Interpret bot weights and nested strategy positions | [Allocation weight drift](https://api.alphainsider.com/resources/bots.md#allocation-weight-drift), [allocation budgets](https://api.alphainsider.com/resources/bots.md#allocation-budgets), [unscaled values and normalized exceptions](https://api.alphainsider.com/resources/trading.md#unscaled-values) | `getBotAllocations`, `updateBotAllocations` |
| Choose fixed, target, or signal execution | [Execution choice](https://api.alphainsider.com/resources/trading.md#execution-choice), [sessions](https://api.alphainsider.com/resources/trading.md#sessions-and-availability) | `newOrder`, `newOrderAllocations`, `newOrderWebhook` |
| Reconcile an order or cancel a prerequisite | [Order requirements and lifecycle](https://api.alphainsider.com/resources/trading.md#order-requirements-and-lifecycle) | `getOrders`, `getPositions`, `getStrategyTimelines`, `deleteOrder` |

Exact request and response schemas are linked from the [API navigation index](https://api.alphainsider.com/resources/agent-skill.md#api-navigation).

##### Inputs and precision

API numbers commonly arrive as strings. Parse them directly into a decimal type (for example Python `Decimal` from a string), not through a binary floating-point value. Use a decimal precision sufficient for the API's fractional units; the examples use 34 significant digits. Keep full precision during intermediate calculations and order serialization. Round only the final human display, or when the operation explicitly requires a particular increment.

Reject missing, nonnumeric, or non-finite required inputs. A multiplier must be finite and strictly positive. A denominator (`strategy_value`, baseline value, or position cost total) must be nonzero; report the calculation as unavailable instead of dividing by zero. Do not substitute `1`, fabricate a quote, or convert an invalid input to zero. Check for missing quotes with a null/missing test, not a truthiness test that discards a legitimate zero.

Each example is independent. `D` below is `Decimal`, and all literal amounts enter as strings. These are worked formulas, not executable API helpers.

This validation example accepts a numeric string, rejects invalid multipliers, and preserves an unavailable result. Apply the same finite-input check to amounts, prices, and denominators before their formulas; additionally reject zero denominators. A missing multiplier may enable the subscriber percentage fallback, but never owner dollar display or user-denominated order conversion.

```python theme={null}
# example: invalid-inputs
from decimal import Decimal as D, InvalidOperation
results = []
for raw in ['4000', None, '0', '-1', 'NaN', 'Infinity', 'invalid']:
    try:
        multiplier = D(raw)
        if not multiplier.is_finite() or multiplier <= 0:
            raise ValueError('Invalid multiplier')
        result = D('100') / multiplier
    except (InvalidOperation, TypeError, ValueError):
        result = None  # Unavailable; do not submit an order.
    results.append(result)
# Expected results: [Decimal('0.025'), None, None, None, None, None, None]
```

For denominators, validate finiteness first and make zero explicitly unavailable. For example, current value 3 with baseline 2.5 returns 20%; with baseline 0 it has no defined return:

```python theme={null}
# example: zero-denominators
from decimal import Decimal as D
returns = []
for baseline in [D('2.5'), D('0')]:
    returns.append((D('3') - baseline) / baseline * D('100') if baseline != 0 else None)
# Expected returns: [Decimal('20'), None]
```

##### Multiplier context

`input_multiplier` translates strategy-normalized units into one user's display scale. It belongs to a particular strategy, user/subscription, and input date. Do not reuse it across contexts.

Owners set their simulated starting value through `newStrategy.input_value` or `updateStrategy.input_value`. Resolve the owner's multiplier from the authenticated subscription/calculation context. If missing, refresh that context; do not fall back to percent display or submit a user-denominated fixed order until it is available.

Subscribers/non-owners prefer their saved `getStrategySubscriptions.input_multiplier`. With a supplied `input_value` and `input_date`, use `getStrategyCalculation` for an unpersisted calculation; use `updateStrategyCalculation` only when the user wants to persist it for an authenticated subscription. Use `deleteStrategyCalculation` only when requested.

An absent or null multiplier means no saved calculation. Some response schemas currently type this field as a string without expressing nullability; handle missing/null explicitly rather than parsing it as a number.

Without a subscriber multiplier, show explicitly labeled percentages using the formulas below, or ask for calculation inputs. Do not show dollars/shares or translate a user-denominated fixed order without a multiplier. Explicitly supplied normalized units may be used as normalized units, with that unit choice made clear. Refresh the context after a strategy reset or a changed input value/date.

##### Get a multiplier

Read the matching subscription's `input_multiplier` from `getStrategySubscriptions`. For a subscriber calculation preview, send `strategy_id`, `input_value` in display currency, and `input_date` as query parameters to `getStrategyCalculation`. To save that calculation, send those fields in the JSON body of `updateStrategyCalculation`.

AlphaInsider selects the available historical baseline and returns `input_multiplier`, `input_date`, and `strategy_value`. Use the returned date and baseline for that calculation context; they may differ from the requested date and today's strategy value. Do not reconstruct the multiplier from current quotes or send a calculated multiplier as an input.

For example, if the response contains `input_multiplier: "4000"`, parse that value as a decimal and use it in the conversions below. Require a finite, strictly positive multiplier. If the calculation request fails or the multiplier is unavailable, follow [multiplier context](https://api.alphainsider.com/resources/trading.md#multiplier-context) before displaying values or preparing an order.

##### Display values

Inputs: a normalized value and the matching `input_multiplier`. Preserve the field's meaning: normalized portfolio/cash values become display currency; normalized position/trade quantities become display shares or crypto units.

```text theme={null}
display_value = normalized_value * input_multiplier
```

Example: a normalized quantity of 0.0125 and multiplier 4,000 represent 50 shares/crypto units. A normalized portfolio value of 3 with the same multiplier represents \$12,000.

```python theme={null}
# example: display
from decimal import Decimal as D, localcontext
with localcontext() as context:
    context.prec = 34
    input_multiplier = D('4000')
    display_quantity = D('0.0125') * input_multiplier
    display_portfolio = D('3') * input_multiplier
# Expected display_quantity: 50; display_portfolio: 12000
```

For a subscriber without a multiplier, `portfolio_percent = strategy_value * 100` reports percentage of the normalized starting value, not investment return. For example `strategy_value = 1.2` means 120% of that baseline, while its return from a baseline of 1 is 20%. Use the next section's return formula for gain/loss.

##### Fixed-order inputs

Inputs: the user's intended share/crypto quantity or currency amount, and the matching positive multiplier. Convert in the opposite direction from display:

```text theme={null}
newOrder.amount = user_quantity / input_multiplier
newOrder.total = user_dollars / input_multiplier
```

Send exactly one of `amount` or `total`. Keep `price` and `stop_price` in actual market-price units. For example, at multiplier 4,000, a \$100 fixed order uses normalized `total = 0.025`; a 5-share order uses normalized `amount = 0.00125`. These are alternative requests.

```python theme={null}
# example: normalized-order
from decimal import Decimal as D, localcontext
with localcontext() as context:
    context.prec = 34
    input_multiplier = D('4000')
    normalized_total = D('100') / input_multiplier
    normalized_amount = D('5') / input_multiplier
# Expected normalized_total: 0.025; normalized_amount: 0.00125
```

Read `getMaxOrderSize` before large or leveraged fixed orders and follow [order capacity and reserves](https://api.alphainsider.com/resources/trading.md#order-capacity-and-reserves). Its amount/total capacities are normalized: compare normalized order inputs with normalized capacities, and multiply capacities by the matching multiplier only for display. A missing owner multiplier blocks conversion; a subscriber must set a calculation or explicitly supply normalized units.

##### Order capacity and reserves

Call `getMaxOrderSize` with the order's `strategy_id` and `stock_id`. AlphaInsider accounts for current positions and open orders; use its returned capacities rather than rebuilding collateral or buying-power calculations. Its capacities have these units and uses:

| Field | Unit | Use |
| - | - | - |
| `buying_power_total` | Normalized cash | Cash capacity for a buy, including the effect of covering existing shorts |
| `selling_power_total` | Normalized cash | Capacity for a sell, including the effect of reducing existing longs |
| `remaining_assets_amount` | Normalized quantity | Long quantity remaining after open sell orders |
| `remaining_liabilities_amount` | Normalized quantity, positive magnitude | Short quantity remaining after open buy orders |
| `fee`, `slippage` | Fractions | Sizing reserves; never multiply these rates by the multiplier |

Do not add closing quantities to the cash capacities a second time. For an exact close, use the appropriate remaining quantity with `amount`, then reconcile after execution. For a fixed-order cash-capacity estimate, the caller can reserve the returned fee and slippage fractions as follows. This estimate is separate from the fees AlphaInsider applies at execution; allocation and webhook endpoints handle their own sizing reserves.

```text theme={null}
reserved_capacity = raw_capacity * (1 - fee - slippage)
display_capacity = raw_capacity * input_multiplier
display_reserved_capacity = reserved_capacity * input_multiplier
```

Require finite, nonnegative capacities and rates, `fee + slippage < 1`, and a positive multiplier for display. Missing or invalid values make the estimate unavailable. Use the selected buy/sell field and choose `amount` or `total` according to [which side of the order must be exact](https://api.alphainsider.com/resources/trading.md#fees-and-exact-order-sizes). Market quotes, open orders, and collateral can change, so a capacity estimate does not guarantee acceptance or execution. Do not round an order up to the estimate.

Example: normalized buying power `2`, multiplier `4000`, fee `0.0025`, and slippage `0.005` give \$8,000 raw capacity and \$7,940 after reserves.

```python theme={null}
# example: order-capacity
from decimal import Decimal as D, localcontext
with localcontext() as context:
    context.prec = 34
    raw_capacity, multiplier = D('2'), D('4000')
    fee, slippage = D('0.0025'), D('0.005')
    reserved_capacity = raw_capacity * (1 - fee - slippage)
    display_capacity = raw_capacity * multiplier
    display_reserved_capacity = reserved_capacity * multiplier
# Expected reserved_capacity: 1.985; display_capacity: 8000; display_reserved_capacity: 7940
```

##### Fees and exact order sizes

Choose the field that expresses the user's intent, then apply only the [fixed-order unit conversion](https://api.alphainsider.com/resources/trading.md#fixed-order-inputs). AlphaInsider calculates the execution price, fees, and the other side of the trade.

| Request | What the supplied value fixes | What AlphaInsider calculates |
| - | - | - |
| Buy `amount` | Quantity received | Cash spent, including fees |
| Buy `total` | Cash spent, including fees | Quantity received |
| Sell `amount` | Quantity removed | Cash received after fees |
| Sell `total` | Cash received after fees | Quantity removed |

For example, to spend \$100 at multiplier 4,000, send `total: "0.025"`; AlphaInsider applies fees within that cash amount. To sell all remaining units, use the returned remaining quantity as `amount`. A sell with `total` can require more units than its cash target divided by the quoted price because fees reduce the proceeds.

Do not adjust the chosen exact input again to apply execution fees. After execution, use the trade timeline's `data.amount`, `data.price`, `data.total`, and `data.fee_total`. The returned `total` is actual cash spent or received after accounting for fees. Multiply normalized amounts and cash totals by the matching multiplier for display. Do not add or subtract the fee again. See [orders and timelines](https://api.alphainsider.com/resources/trading.md#orders-and-timelines) for a worked response example.

##### Performance and baselines

Inputs: current and baseline normalized `strategy_value`, plus the multiplier when displaying currency. If the requested performance series includes the saved `input_date`, use the calculation's strategy value at that date as the baseline. Otherwise use the first strategy value in the selected window. State which baseline/window the result uses.

```text theme={null}
dollar_gain_loss = (current_strategy_value - baseline_strategy_value) * input_multiplier
percent_gain_loss = ((current_strategy_value - baseline_strategy_value) / baseline_strategy_value) * 100
```

The percentage formula needs a nonzero baseline and does not need a multiplier. Owner dollar display still requires the owner multiplier; percent-only fallback is for subscribers without one. Example: 2.5 to 3 is a 20% return and a \$2,000 gain with multiplier 4,000.

```python theme={null}
# example: performance
from decimal import Decimal as D, localcontext
with localcontext() as context:
    context.prec = 34
    baseline = D('2.5')
    current = D('3')
    dollar_gain_loss = (current - baseline) * D('4000')
    percent_gain_loss = ((current - baseline) / baseline) * D('100')
# Expected dollar_gain_loss: 2000; percent_gain_loss: 20
```

##### Position valuation

Inputs: signed normalized position `amount`, current normalized portfolio `strategy_value`, actual market quotes, and the multiplier when showing currency/quantity. Use `bid` for a long/asset (`amount >= 0`) and `ask` for a short/liability (`amount < 0`). If the selected quote is missing, fall back to stored position `price`; if both are unavailable, stop that valuation. Cash uses price `1`.

For example, a long position with no bid and stored price 100 uses 100 with a fallback label. The same position without either price has no available valuation. A supplied bid of zero stays zero; it is not replaced by the stored price. Non-finite or nonnumeric quotes are invalid inputs, not missing quotes.

```python theme={null}
# example: quote-selection
from decimal import Decimal as D
selected_prices = []
# amount, bid, ask, stored price, is cash; all supplied numbers are already validated.
cases = [('0.1', '100', '110', '90', False), ('-0.1', '100', '110', '90', False),
         ('0.1', None, '110', '90', False), ('0.1', None, '110', None, False),
         ('0.1', '0', '110', '90', False), ('5', None, None, None, True)]
for amount, bid, ask, stored_price, is_cash in cases:
    quote = '1' if is_cash else (bid if D(amount) >= 0 else ask)
    if quote is None:
        quote = stored_price
    selected_prices.append(D(quote) if quote is not None else None)
# Expected selected_prices: [Decimal('100'), Decimal('110'), Decimal('90'), None, Decimal('0'), Decimal('1')]
```

```text theme={null}
signed_market_value = amount * current_price * input_multiplier
liability_magnitude = abs(amount) * current_price * input_multiplier
signed_exposure_percent = ((amount * current_price) / strategy_value) * 100
cash_value = cash_amount * input_multiplier
cash_percent = (cash_amount / strategy_value) * 100
```

Keep signed exposure negative for shorts. A positive liability magnitude is a different presentation and must be labeled as such. A subscriber without a multiplier may display exposure/cash percentages, not dollar values or unit quantities. `strategy_value` must be nonzero.

Example with portfolio value 50 and multiplier 200: long amount 0.1 at bid 100 has 20% exposure and \$2,000 value; short amount -0.1 at ask 110 has -22% exposure, -\$2,200 signed value, and \$2,200 liability magnitude. Cash amount 5 represents \$1,000 and 10% of the portfolio.

```python theme={null}
# example: valuation
from decimal import Decimal as D, localcontext
with localcontext() as context:
    context.prec = 34
    strategy_value = D('50')
    multiplier = D('200')
    long_exposure = D('0.1') * D('100') / strategy_value * D('100')
    short_exposure = D('-0.1') * D('110') / strategy_value * D('100')
    long_value = D('0.1') * D('100') * multiplier
    short_value = D('-0.1') * D('110') * multiplier
    liability_magnitude = abs(short_value)
    cash_value = D('5') * multiplier
    cash_percent = D('5') / strategy_value * D('100')
# Expected long_exposure: 20; short_exposure: -22; long_value: 2000
# Expected short_value: -2200; liability_magnitude: 2200; cash_value: 1000; cash_percent: 10
```

##### Position gain and loss

Use the current price selected above. The REST position's `price` is its stored entry price; a client may name that entry price `avg_price`. Do not confuse a fallback valuation quote with a newly observed market quote.

For currency gain/loss, inputs are signed normalized amount, current/entry actual market prices, and the positive multiplier:

```text theme={null}
position_gain_loss_amount = amount * (current_price - entry_price) * input_multiplier
```

For percentage gain/loss, use the position's signed normalized `total` (cost total), not portfolio value. The total must be nonzero:

```text theme={null}
raw_gain_loss_percent = (((amount * current_price) - position_total) / position_total) * 100
position_gain_loss_percent = raw_gain_loss_percent * (-1 if amount < 0 else 1)
```

Do not apply the multiplier to gain/loss percent. Example: a short amount -0.1 entered at 100, now quoted at 110, with cost total -10 and multiplier 200 has a \$200 loss and -10% return. The corresponding long has a \$200 gain and +10% return.

```python theme={null}
# example: position-profit
from decimal import Decimal as D, localcontext
with localcontext() as context:
    context.prec = 34
    amount = D('-0.1')
    current_price = D('110')
    entry_price = D('100')
    position_total = D('-10')
    gain_loss_amount = amount * (current_price - entry_price) * D('200')
    raw_percent = ((amount * current_price - position_total) / position_total) * D('100')
    gain_loss_percent = raw_percent * (D('-1') if amount < 0 else D('1'))
    long_gain_loss_amount = D('0.1') * (current_price - entry_price) * D('200')
    long_gain_loss_percent = ((D('0.1') * current_price - D('10')) / D('10')) * D('100')
# Expected gain_loss_amount: -200; gain_loss_percent: -10
# Expected long_gain_loss_amount: 200; long_gain_loss_percent: 10
```

##### Orders and timelines

Open order `amount` and `total` are normalized. Multiply each non-null field by the matching multiplier for display. A null `total` is not zero. When a valid price exists, `amount * price` gives an estimated gross notional for percent display; label it as an estimate. Use the returned trade total for actual cash movement after execution.

```text theme={null}
display_order_amount = order_amount * input_multiplier
display_order_total = order_total * input_multiplier
order_percent = (normalized_order_total / strategy_value) * 100
display_trade_amount = trade_amount * input_multiplier
display_trade_total = trade_total * input_multiplier
display_trade_fee = trade_fee_total * input_multiplier
trade_percent = ((trade_amount * trade_price) / trade_strategy_value) * 100
```

For historical timeline percentages use `data.strategy_value` at that trade, not today's portfolio value. Use returned `data.total` for actual cash movement and `data.fee_total` for fees; multiply both by the matching multiplier for display. Apply the same quantity rules to holdings changes. Owner displays require the owner multiplier; subscriber percentages are the fallback when theirs is absent.

Example: a sell trade returns amount `0.02`, price `125`, total `2.475`, fee total `0.025`, and contemporaneous strategy value `5`. With multiplier 4,000, display 80 units, \$9,900 received, \$100 in fees, and 50% gross exposure. The returned cash total already accounts for the fee.

```python theme={null}
# example: order-timeline
from decimal import Decimal as D, localcontext
with localcontext() as context:
    context.prec = 34
    trade_amount = D('0.02')
    trade_price = D('125')
    trade_strategy_value = D('5')
    trade_total = D('2.475')
    trade_fee_total = D('0.025')
    display_trade_amount = trade_amount * D('4000')
    display_trade_total = trade_total * D('4000')
    display_trade_fee = trade_fee_total * D('4000')
    trade_percent = (trade_amount * trade_price) / trade_strategy_value * D('100')
# Expected display_trade_amount: 80; display_trade_total: 9900; display_trade_fee: 100; trade_percent: 50
```

##### Unscaled values

Do not convert actual market `price`, `bid`, `ask`, `last`, or `stop_price`, fee/slippage rates, allocation percentages, or webhook signals. A rate is distinct from a cash total: derive and label a cash display only when the field is documented as a normalized cash amount.

Real broker portfolio values, cash, positions, `getBotInfo.broker_details`, and `getBotPerformance.portfolio_value` are already user-facing. Do not multiply them again. However, `getBotAllocations.positions` contains normalized strategy positions and uses the strategy's own context. `getMaxOrderSize` quantities and cash capacities are also normalized; follow [order capacity and reserves](https://api.alphainsider.com/resources/trading.md#order-capacity-and-reserves).

Example: a broker portfolio value of \$10,000 allocated at 0.25 has a \$2,500 allocation budget regardless of a strategy's multiplier. A market price of 100 remains 100.

```python theme={null}
# example: unscaled
from decimal import Decimal as D, localcontext
with localcontext() as context:
    context.prec = 34
    broker_value = D('10000')
    allocation = D('0.25')
    allocation_budget = broker_value * allocation
    market_price = D('100')
# Expected allocation_budget: 2500; market_price: 100
```

##### Execution choice

* `newOrder` creates one fixed order from exactly one normalized `amount` or `total`. Construct only fields accepted by its current schema; price and stop price remain market prices. Compare normalized inputs with the applicable normalized `getMaxOrderSize` capacities, allowing for fees and slippage.
* `newOrderAllocations` specifies the complete desired position set. Batch coexisting targets in one request; it cancels existing open orders and closes omitted positions. Each target includes `stock_id`, `action`, and decimal `percent` from 0 through 2 in increments of 0.0001; the combined target percent must be at most 2. Zero is accepted and close/flat ignores the supplied percent. An empty allocation list closes all positions. Allocation percentages are fractions, not numbers from 0 to 100. No multiplier conversion applies.
* `newOrderWebhook` uses signal-style actions and a body `api_token`. By default it goes fully in/out at its leverage; `pyramiding` splits entry into steps across same-direction alerts. Send the signal settings and let AlphaInsider calculate each step's order size. It cancels existing open strategy orders first. No multiplier conversion applies.
* `order_dependencies` in responses identifies prerequisite order IDs. `newOrder` also accepts it as an optional request field: resolve and confirm the prerequisite orders belong to the same strategy before supplying their IDs. Do not send it to allocation or webhook endpoints, which calculate their own dependencies. Empty response dependencies mean no prerequisite; they do not guarantee a fill.
* An instrument's `provider` identifies its market-data source, such as `massive` for stock quotes. A bot's `broker` identifies its connected brokerage.
* Allocation-generated orders are market orders. Their `slippage` parameter contributes to sizing reserves. Inspect returned order types and dependencies.
* Confirm exact current operation limits and side effects before acting. Do not replay an uncertain submission; reconcile orders/positions and the prior result first. Strategy Creator's confirmed execution and no-same-trigger-retry rules continue to apply.

##### Order requirements and lifecycle

Read [authentication and requests](https://api.alphainsider.com/resources/introduction.md#authentication-and-requests) and the [shared order limiter](https://api.alphainsider.com/resources/limits.md#operation-specific-limits) before submitting. A fixed order needs exactly one finite positive `amount` or `total`. Any supplied price must be finite and positive.

| Type | Required price fields |
| - | - |
| `market` | None |
| `limit` | `price` |
| `stop_market` | `stop_price` |
| `stop_limit` | `price` and `stop_price` |
| `oco` | `price` and `stop_price` |

At OCO submission, a buy requires `price <= bid <= stop_price`; a sell requires `stop_price <= ask <= price`. Use the current quotes and recheck after a rejection; do not change the user's intended prices automatically.

Successful creation returns an open order. Keep the submitted intent and returned order IDs so an accepted/pending request is distinguishable from an executed trade. `getOrders` and `wsOrders` report open orders, not an order-history ledger. Both execution and cancellation can remove an order from this list. Trade timeline records have a `history_id`; the API does not expose a persisted order-ID-to-fill mapping or a client idempotency key.

After an uncertain submission or cancellation, read current open orders, positions, and strategy trade timelines before deciding whether another action is needed. An absent order or a similar-looking trade alone does not prove that a particular request executed. Leave attribution unresolved when the available state cannot establish it. Do not replay the request automatically or recreate a supposedly missing order.

`order_dependencies` waits for referenced open orders to be removed. Cancelling a prerequisite releases its dependents just as deleting it after execution does; it does not cancel the dependent orders. After cancelling, re-read all remaining strategy orders and positions. Do not assume a prerequisite filled because its ID disappeared. Any decision to cancel other orders remains part of the caller's authorized workflow.

For stream interruptions, follow [connection and recovery](https://api.alphainsider.com/resources/websockets.md#connection-and-recovery) and refresh REST snapshots. Reconnecting is not a reason to submit or replay an order.

##### Sessions and availability

`getExchangeStatus` reports stock and cryptocurrency status strings. A valid order can be accepted while the exchange is closed and remain pending. Market-price updates trigger order processing when the provider's exchange status is `open`; updates received with another status update current quotes without triggering that processing. Submission success and an `extended-hours` status therefore do not establish execution or an immediate fill. Dependencies and order-price conditions still apply.

A caller such as Strategy Creator may impose a stricter schedule. Keep that caller policy separate from submission/execution behavior, and do not expand an already confirmed schedule without authorization.

##### Agent checklist

* Resolve the correct user's multiplier before dollar/share display or user-denominated fixed orders; subscriber percent fallback must be labeled.
* Compare like units, reserve fees/slippage, and distinguish exact quantity from cash after fees.
* Check both HTTP status and `success`, then distinguish accepted orders from completed trades.
* Reconcile uncertain outcomes and cancellation dependencies before any further mutation.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.