Time Seventeen | Trading Workflow

Authorization -> protected limit order -> acknowledgement -> order/fill stream -> position -> settlement, using non-executable illustrative values.

Draft v0.1 — design contract, not yet a live service

This documentation set defines a proposed Time Seventeen protocol for review and implementation planning. https://api.t17.capital is the approved and reserved REST origin, but neither that origin nor any documented endpoint is claimed to be live. The WebSocket origin remains unspecified. Credentials, chain IDs, contract addresses, rate limits, and SLAs remain unapproved; IDs, prices, and timestamps shown throughout are illustrative, not real production data.

Not executable

Every request on this page targets the reserved REST origin https://api.t17.capital/v1 and uses illustrative signatures (0xDEMOSIGNATUREPLACEHOLDER). Endpoint availability is not implied, and nothing here can place a real order.

This walkthrough shows how the pieces of the trading protocol fit together, in the order a real integration would exercise them.

1. Establish account authorization (EIP-712)

Before any order, an owning wallet signs a T17ApiAuthorization delegating scopes to an API key. See Authentication → EIP-712 account authorization.

2. Sign and submit a protected limit order

A market-style execution is a marketable limit order with FOK or FAK, never an unbounded market order.

POST /orders
Idempotency-Key: idem_demo_7f2a

Illustrative signed request only — not executable

{
  "client_order_id": "corder_demo_0001",
  "market_id": "mkt_demo_001",
  "outcome_id": "out_demo_001",
  "side": "BUY",
  "order_type": "limit",
  "limit_price": "0.6400",
  "quantity": "150.00",
  "time_in_force": "GTC",
  "post_only": false,
  "reduce_only": false,
  "self_trade_prevention": "cancel_taker",
  "settlement_asset_id": "asset_demo_collateral_001",
  "signature_type": "eoa",
  "signature_version": "1",
  "order_nonce": "order_nonce_demo_4401",
  "order_signature": "0xDEMOSIGNATUREPLACEHOLDER"
}

3. Read the acknowledgement

{
  "data": { "order_id": "ord_demo_001", "status": "open", "received_at": "2026-08-31T12:00:00.100Z" },
  "meta": { "request_id": "req_demo_order_001", "schema_version": "1.0" }
}

Acknowledgement means the command was accepted for processing — it is not a fill.

4. Watch the private order and fill streams

{ "action": "subscribe", "topic": "account.order", "subscription_id": "sub_demo_020" }

{ "action": "subscribe", "topic": "account.fill", "subscription_id": "sub_demo_021" }

account.order reports state transitions (open → partially_filled → filled, or a terminal canceled/rejected/expired); account.fill reports each immutable execution.

5. Confirm the position

GET /positions/mkt_demo_001

Note that unsettled_quantity may remain non-zero even after every relevant order/fill reaches a terminal state — settlement is a separate lifecycle.

6. Track settlement to finality

GET /settlements?market_id=mkt_demo_001

Watch state progress from pending/submitted to confirmed, and eventually redeemable. POST /settlements/{settlement_id}/redeem remains a design placeholder in Draft v0.1.

Where to go next

Concepts → Trading Lifecycle for the conceptual state machine.
API Reference → Orders, Fills, Positions, and Settlement for the full contract.
API Reference → WebSocket for the private stream envelope and gap-recovery rules.

Trading Workflow