Messages

Every frame, in both directions, is a JSON object with the same envelope. A message’s own fields live in payload and nowhere else.

Field	Type	On	Meaning
`type`	string	every frame	Which message this is
`payload`	object	most frames	The message’s fields. Absent on messages that carry none
`requestId`	string	every message you send; echoed on its reply	Your id for the message, at most 32 characters. See below
`timestamp`	integer	signed messages	Unix seconds. See Signing
`signature`	string	signed messages	Base58 Ed25519 signature
`for`	string	`ack`	Which request the `ack` answers: `place_order`, `get_mints`…
`traceId`	string	every server frame	Securitize’s id for the exchange. Quote it to support
`sentAt`	string	every server frame	When the server put the frame on the wire. ISO 8601, UTC, milliseconds

{
  "type": "get_cash_movements",
  "requestId": "9c31a5e72d4b4f80b1c67e3a9d0f5b24",
  "payload": { "limit": 10 }
}

{
  "type": "ack",
  "for": "get_cash_movements",
  "requestId": "9c31a5e72d4b4f80b1c67e3a9d0f5b24",
  "traceId": "partners-rt-gw-7d0e4b21-9c3f-4a58-b7e1-2f6d8a0c4e93",
  "sentAt": "2026-08-27T13:02:44.906Z",
  "payload": { "movements": [] }
}

Replies and pushes

A reply carries your requestId. The server never interprets it and does not enforce uniqueness. A message without one is accepted, but then two replies of the same type cannot be told apart. Send one on every message, and one generic send(message) → reply helper can serve every operation. Keep it to 32 characters. Up to 64 are accepted, but an error echoes only the first 32, followed by …, so a longer one matches nothing on a refusal. A UUID without its hyphens is exactly 32 characters. A reply is welcome, pong, an ack, or an error carrying the requestId of the message that caused it. A frame refused at envelope level, before its requestId can be read (a malformed envelope, duplicate keys), answers an error with traceId alone. A push carries no requestId, because nothing asked for it. That absence is what tells order_updated, trade_updated, mint_updated, burn_updated and cash_movement apart from replies.

Three ids that look alike

Field	Set by	For
`requestId`	You	Matching a reply to its request
`traceId` on the envelope	Securitize	Support: quote it and Securitize can follow the exchange end to end. Opaque; do not store it as a business key
`traceId` on a mint or a burn	Securitize	A business key: the short base58 handle at the end of the mint’s memo, which `get_mints` and `get_burns` take. Store it. See Mints and burns

The two traceIds share a name and nothing else.

Times

Field	Says
`sentAt`	When Securitize put the frame on the wire. Not when anything happened at the broker
`createdAt`	When the broker created the order
`occurredAt`	The broker’s time for an update, a fill or a ledger entry. Orders two updates of one order
`executedAt`	When an execution happened. Orders executions and trades
`timestamp`, `serverTime`	Unix seconds: your signing time, and the server clock

Amounts

Every amount is a decimal string, never a JSON number, in both directions: "quantity": "10.5", not 10.5. A JSON number is a double, and fractional quantities do not survive one intact. Compare amounts as decimals, never as strings. The broker sets the number of decimal places, and it is not preserved: a limitPrice of "1.00" can come back as "1", a quantity of "1" as "1.000000", and two fields in one frame can carry different scales. Parse with a decimal type (Decimal in Python, a decimal library in JavaScript). What you send is limited in decimal places:

Field	At most
`quantity`	5 decimal places
`limitPrice`	2 decimal places at 1.00 or more; 4 under 1.00

Get started

Sandbox only

Guides

Concepts

Help

API reference

Replies and pushes

Three ids that look alike

Times

Amounts