Skip to main content
This feature is in public preview.
The orderbook is the public, anonymized record of buy and sell orders on the market. Each order states its side, node count, SKU, delivery window, and limit price. The diagram below shows 3 example open orders. Orderbook with three example open orders: a Buy for 8 H100s on Sep 1 9am to Sep 4 5pm at up to $17.42/node-hour, a Sell for 4 B200s on the same window at $17.38 minimum, and a Buy for 16 H200s on Oct 15 12am to Oct 22 12am at up to $16.95. The trading engine matches compatible buys and sells continuously. Open orders make up the live book; filled orders and their executions provide market history. Orderbook responses never expose participant, pool, or capacity identity. Endpoints live under /preview/v2/orderbook/ and require a Bearer token; see Using the API.
  • /orders lists individual open and filled orders.
  • /windows lists active SKU and delivery-window combinations in a time range.
  • /quote returns the top of book (best bid and best ask) for one exact window.
  • /depth returns the live book aggregated at every SKU and price level.
  • /fills lists individual executions produced when orders match.
/windows, /quote, and /depth are derived views of open orders, while /fills is an execution-level view. Use /windows when you don’t yet know the exact window. The other endpoints price or trace a window you’ve already picked. To create, cancel, or inspect your own workspace’s orders, see Orders. The hardware filter is ?requirements=key:value. Keys are SKU property names such as accelerator, region, or availability_zone. Values are case-sensitive and match the property’s value spelling, as in accelerator:h100. Run sf skus list to see the properties a SKU carries. Each key takes exactly one value; combine keys with ; to require all of them, as in accelerator:h100;availability_zone:a. The reserved instance_sku key matches a single SKU by its ID. The filter covers every SKU that satisfies these requirements. All timestamps are Unix epoch seconds. Field names use the _at suffix. Delivery-window and range boundaries (start_at, end_at, range_start_at, and range_end_at) must be aligned to whole minutes.

​
Orders

List individual open and filled orders created within the last 30 days whose delivery windows match a time range. Results are anonymized and sorted newest first by created_at.
open includes standing and partially filled orders; filled means the order filled completely. Pending, cancelled, and rejected orders are not returned. Omit status to include both public statuses, or repeat it to select more than one. Use side=buy for buys or side=sell for sells. Delivery windows are half-open ranges: [start_at, end_at). window_relation=overlaps is the default. contained_within requires the order’s full window to be inside the requested range. exact requires the windows to match. The range is capped at 30 days. limit defaults to 50 and caps at 200; pass the returned cursor as starting_after to fetch the next page. The cursor must reference an order created within the last 30 days; older cursors return a 422 response.

​
Windows

Enumerate every SKU and delivery window that currently has open orders matching the requirements filter, within a time range. Three example delivery windows displayed as horizontal bars on a Sep 1 to Sep 29 time axis, each showing its bid and ask counts.
A window appears when it holds at least one matching open order and sits entirely within the range. best_bid / best_ask are omitted when that side is empty. Results are sorted ascending by (start_at, end_at, instance_sku) and cursor-paginated. limit defaults to 50 and caps at 200; the range is capped at 365 days.

​
Quote

Get the top of book for one exact window: the highest bid and lowest ask. A vertical price ladder showing best ask of $17.42 with 2 nodes above best bid of $17.38 with 4 nodes, with a vertical bracket between them labeled spread $0.04.
Each side carries an allocation_schedule_delta: the unfilled nodes at that rate and SKU over time. If multiple SKUs tie at the best price, the quote returns the SKU that sorts first by ID. Use /depth to inspect every SKU at that price. The window’s end_at must be in the future; read past windows through /fills.

​
Depth

Get the depth of book aggregated by SKU and dollars-per-node-hour rate across the hardware matching the requirements filter. Level II ladder showing two ask price levels above the spread and three bid price levels below, with horizontal bars whose lengths encode the node count at each price.
Bids are sorted by descending rate (best bid first); asks are ascending. Orders at the same rate and SKU collapse into one level. depth defaults to 20 and caps at 100 per side. The window’s end_at must be in the future; read past windows through /fills.

​
Fills

List individual executions for one exact delivery window. A single order can produce multiple fills, and each fill records the nodes and price that actually traded.
since_at is a lower bound on when the fill was recorded. It defaults to 7 days before the request. Values more than 30 days before the request return 422. Results are sorted newest first and cursor-paginated. limit defaults to 50 and caps at 200.

​
Allocation schedule deltas

allocation_schedule_delta describes how many nodes an order requests or offers during one or more time intervals. An allocation_schedule_delta JSON entry mapped to eight nodes over a time interval. start_at supplies the time for vertices A and B, end_at supplies the time for C and D, and node_count supplies the value for B and C. Each object in the array is one schedule segment. start_at and end_at set the segment’s time bounds, while node_count specifies how many nodes apply during that interval. Multiple entries can describe different node counts over adjacent intervals. Schedule entries describe half-open intervals [start_at, end_at): the node count applies at start_at, but not at end_at. Adjacent entries therefore meet without overlapping. All segments on an order refer to that order’s single instance_sku. In responses, a non-empty array always ends with a terminator entry whose end_at is null and node_count is 0, marking the schedule as open-ended and empty after the last segment. A schedule with no capacity is returned as an empty array. Requests carry only the closed [start_at, end_at) segments you submit and omit this terminator. Orders are submitted with one node count over one delivery window, so allocation_schedule_delta normally contains one segment. filled_allocation_schedule_delta describes the portion that has executed so far and may contain multiple segments when different parts of the order fill over different intervals. Subtract the filled node count from the requested or offered node count at each instant to get the capacity that remains on the book. For a buy, every filled segment adds to the destination pool’s allocation schedule; for a sell, it removes that segment. An orderbook fill reports the exact schedule segment that traded. To calculate the compute represented by a schedule, sum node_count × duration_hours across its entries.

​
API reference

See the Orderbook API reference for full request and response schemas.