Logs

List logs for a ledger

Changed on

Lists log entries for a specific ledger, paged by ledger-local log ID (ascending unless reverse=true). Requires the builtin LOG index to be enabled on the ledger via CreateIndex. Requires ledger:read scope.

get/v3/{ledgerName}/logs

Request

  • Base URL
    http://localhost:9000
  • URL
    http://localhost:9000/v3/{ledgerName}/logs
  • Auth
    • HTTP bearer
    • or none

Path parameters

ledgerNamestring required

Name of the ledger

Query parameters

pageSizeinteger

Maximum number of items per page. 0 or absent means 100; values above 1000 are clamped to 1000.

cursorstring

Page token of a paged list. Clients normally pass back the next or previous value of a previous response verbatim; building one by hand is supported.

A token is base64url (unpadded, RFC 4648 §5) of the JSON object {"key": <string>, "back": <bool>}. Both fields are omitted when empty, and unknown fields are rejected. key is a position in the endpoint's textual form:

  • transactions: decimal transaction id
  • logs: decimal ledger-local log id
  • audit entries: decimal audit sequence
  • accounts: address
  • ledgers and numscripts: name
  • signing keys: key id
  • prepared queries: decimal id for TRANSACTIONS and LOGS targets, address for ACCOUNTS
  • index inspection: base64url of the encoded metadata value

Both directions exclude the key and return rows in the requested order (reverse included):

  • {"key": K} serves the rows strictly after K;
  • {"key": K, "back": true} serves the page that ends strictly before K;
  • {"back": true} serves the last page;
  • an absent or empty token, or e30 ({}), serves the first page.

On a forward page, next is set when a further row follows the page, and previous whenever the request carried a key. On a back page, previous is set when a further row precedes the page, and next whenever the request carried a key. A first page therefore has no previous, and the last page requested with {"back": true} has no next. A malformed token, or a key that is not a valid position for the endpoint, is rejected with 400 INVALID_REQUEST.

Page token from a previous response's next or previous field (see the PageToken schema). Omit for the first page. Pass the same reverse and filter on every page of a walk.

reverseboolean

List in descending ledger-local log ID order when true.

startDatestring date-time

Filter logs with date >= startDate (inclusive, RFC3339 format). Must be on or after the Unix epoch (1970-01-01T00:00:00Z); earlier dates are rejected with a 400. Requires the builtin LOG_DATE index to be enabled on the ledger.

endDatestring date-time

Filter logs with date < endDate (exclusive, RFC3339 format). Must be on or after the Unix epoch (1970-01-01T00:00:00Z); earlier dates are rejected with a 400. Requires the builtin LOG_DATE index to be enabled on the ledger.

filterstring

A filter, accepted in EITHER of two interchangeable representations that parse to the same filter and are validated against the same per-target rules:

  • Textual — the human-readable filter grammar, e.g. metadata[status] == "active", address ^= "users:", metadata[a] == "x" and metadata[b] == "y". Passed verbatim as the query-parameter value (URL-encoded).
  • Structured — the JSON QueryFilter DSL (see the QueryFilter schema: $and/$or/$not + $match/$gt/$exists/…). Passed by URL-encoding the JSON object as the query-parameter value.

A condition that is not valid on the endpoint's target (e.g. a transaction-only condition on the accounts list) is rejected with 400. This generic filter is AND-combined with any convenience parameters the endpoint also exposes (e.g. the transactions startDate/endDate timestamp range). Selections that used to have dedicated aliases are expressed through this filter: an account address prefix via filter=address ^= "users:", a transaction reference via filter=reference == "..." or filter={"$match":{"reference":"..."}} (URL-encoded).

Both representations cover the same fields under the same names: metadata[<key>], address, source, destination, reference, reverted, ledger, id, timestamp, insertedAt, revertedAt, logId, date (e.g. textual id > 100 and reverted == false or structured {"$and":[{"$gt":{"id":100}},{"$match":{"reverted":false}}]}).

Date fields accept either an RFC3339 timestamp or raw Unix microseconds, in both representations: on transactions timestamp / insertedAt / revertedAt (e.g. textual filter=timestamp >= "2023-11-14T22:13:20Z" or structured filter={"$gte":{"timestamp":"2023-11-14T22:13:20Z"}}), and on logs date (e.g. filter=date >= "2023-11-14T22:13:20Z"). An RFC3339 value before the Unix epoch (1970-01-01) is rejected with 400.

Note: the bare audit fields (outcome, ledger, seq, proposal_id, timestamp, log_seq, caller_subject, order_type, idempotency_key) are valid only on the audit-entries endpoint, where both representations resolve them against the audit target.

Headers

X-Consistency'linearizable' | 'stale'

Read consistency. linearizable (the default) runs a Raft ReadIndex barrier and waits for the receiving node to apply up to it. stale serves the read from the receiving node's own store, with no barrier and no forwarding to the leader, so the answer may lag the leader. Matching ignores case and surrounding whitespace. An unknown value, or a repeated or comma-joined header, returns 400 INVALID_REQUEST on every /v3 route, writes included; a valid value has no effect on writes. The gRPC equivalent is the x-consistency request metadata.

Formance-Bigint-As-Stringstring

Render all response Uint256, BigUint and SignedBigInt values as canonical decimal strings, regardless of business meaning, including posting amounts, volume input/output and balances. Ordinary integer IDs/counts, metadata and explicitly string-encoded counters keep their existing representation. Case-insensitive true, yes, y and 1 enable this option, matching Ledger v2. Whitespace is not trimmed. Omission and every other value retain JSON number tokens. This affects only this response, including nested objects, maps, arrays, transaction/log/cursor and bulk results. Request decoding is unchanged.

Response

Logs retrieved successfully

nextstring

Page token of a paged list. Clients normally pass back the next or previous value of a previous response verbatim; building one by hand is supported.

A token is base64url (unpadded, RFC 4648 §5) of the JSON object {"key": <string>, "back": <bool>}. Both fields are omitted when empty, and unknown fields are rejected. key is a position in the endpoint's textual form:

  • transactions: decimal transaction id
  • logs: decimal ledger-local log id
  • audit entries: decimal audit sequence
  • accounts: address
  • ledgers and numscripts: name
  • signing keys: key id
  • prepared queries: decimal id for TRANSACTIONS and LOGS targets, address for ACCOUNTS
  • index inspection: base64url of the encoded metadata value

Both directions exclude the key and return rows in the requested order (reverse included):

  • {"key": K} serves the rows strictly after K;
  • {"key": K, "back": true} serves the page that ends strictly before K;
  • {"back": true} serves the last page;
  • an absent or empty token, or e30 ({}), serves the first page.

On a forward page, next is set when a further row follows the page, and previous whenever the request carried a key. On a back page, previous is set when a further row precedes the page, and next whenever the request carried a key. A first page therefore has no previous, and the last page requested with {"back": true} has no next. A malformed token, or a key that is not a valid position for the endpoint, is rejected with 400 INVALID_REQUEST.

previousstring

Page token of a paged list. Clients normally pass back the next or previous value of a previous response verbatim; building one by hand is supported.

A token is base64url (unpadded, RFC 4648 §5) of the JSON object {"key": <string>, "back": <bool>}. Both fields are omitted when empty, and unknown fields are rejected. key is a position in the endpoint's textual form:

  • transactions: decimal transaction id
  • logs: decimal ledger-local log id
  • audit entries: decimal audit sequence
  • accounts: address
  • ledgers and numscripts: name
  • signing keys: key id
  • prepared queries: decimal id for TRANSACTIONS and LOGS targets, address for ACCOUNTS
  • index inspection: base64url of the encoded metadata value

Both directions exclude the key and return rows in the requested order (reverse included):

  • {"key": K} serves the rows strictly after K;
  • {"key": K, "back": true} serves the page that ends strictly before K;
  • {"back": true} serves the last page;
  • an absent or empty token, or e30 ({}), serves the first page.

On a forward page, next is set when a further row follows the page, and previous whenever the request carried a key. On a back page, previous is set when a further row precedes the page, and next whenever the request carried a key. A first page therefore has no previous, and the last page requested with {"back": true} has no next. A malformed token, or a key that is not a valid position for the endpoint, is rejected with 400 INVALID_REQUEST.

hasMoreboolean required

True when a following page exists; set iff next is.

Example response

{
  "data": [
    {
      "payload": {
        "apply": {
          "log": {
            "type": "SET_METADATA",
            "data": {
              "targetType": "ACCOUNT",
              "targetId": "users:alice",
              "metadata": {
                "category": "premium"
              }
            }
          }
        }
      }
    }
  ]
}

Changes