---
title: "Fetch project logs (POST form)"
method: POST
path: "/v1/project_logs/{project_id}/fetch"
tags: ["Logs"]
---

# Fetch project logs (POST form)

`POST /v1/project_logs/{project_id}/fetch`

Fetch the events in a project logs. Equivalent to the GET form of the same path, but with the parameters in the request body rather than in the URL query

## Path parameters

- `project_id` string, uuid, required — Project id

## Request body

- FetchEventsRequest
  - `limit` integer, nullable — limit the number of traces fetched Fetch queries may be paginated if the total result size is expected to be large (e.g. project_logs which accumulate over a long time). Note that fetch queries only support pagination in descending time order (from latest to earliest `_xact_id`. Furthermore, later pages may return rows which showed up in earlier pages, except with an earlier `_xact_id`. This happens because pagination occurs over the whole version history of the event log. You will most likely want to exclude any such duplicate, outdated rows (by `id`) from your combined result set. The `limit` parameter controls the number of full traces to return. So you may end up with more individual rows than the specified limit if you are fetching events containing traces.
  - `cursor` string, nullable — An opaque string to be used as a cursor for the next page of results, in order from latest to earliest. The string can be obtained directly from the `cursor` property of the previous fetch query
  - `max_xact_id` string, nullable — DEPRECATION NOTICE: The manually-constructed pagination cursor is deprecated in favor of the explicit 'cursor' returned by object fetch requests. Please prefer the 'cursor' argument going forwards. Together, `max_xact_id` and `max_root_span_id` form a pagination cursor Since a paginated fetch query returns results in order from latest to earliest, the cursor for the next page can be found as the row with the minimum (earliest) value of the tuple `(_xact_id, root_span_id)`. See the documentation of `limit` for an overview of paginating fetch queries.
  - `max_root_span_id` string, nullable — DEPRECATION NOTICE: The manually-constructed pagination cursor is deprecated in favor of the explicit 'cursor' returned by object fetch requests. Please prefer the 'cursor' argument going forwards. Together, `max_xact_id` and `max_root_span_id` form a pagination cursor Since a paginated fetch query returns results in order from latest to earliest, the cursor for the next page can be found as the row with the minimum (earliest) value of the tuple `(_xact_id, root_span_id)`. See the documentation of `limit` for an overview of paginating fetch queries.
  - `filters` PathLookupFilter[], nullable — NOTE: This parameter is deprecated and will be removed in a future revision. Consider using the `/btql` endpoint (https://www.braintrust.dev/docs/reference/btql) for more advanced filtering. A list of filters on the events to fetch. Currently, only path-lookup type filters are supported.
    - `type` 'path_lookup', required — Denotes the type of filter as a path-lookup filter
    - `path` string[], required — List of fields describing the path to the value to be checked against. For instance, if you wish to filter on the value of `c` in `{"input": {"a": {"b": {"c": "hello"}}}}`, pass `path=["input", "a", "b", "c"]`
    - `value` unknown
  - `version` string, nullable — Retrieve a snapshot of events from a past time The version id is essentially a filter on the latest event transaction id. You can use the `max_xact_id` returned by a past fetch as the version to reproduce that exact fetch.

## Response `200`

Returns the fetched rows

- FetchProjectLogsEventsResponse
  - `events` ProjectLogsEvent[], required — A list of fetched events
    - `id` string, required — A unique identifier for the project logs event. If you don't provide one, BrainTrust will generate one for you
    - `_xact_id` string, required — The transaction id of an event is unique to the network operation that processed the event insertion. Transaction ids are monotonically increasing over time and can be used to retrieve a versioned snapshot of the project logs (see the `version` parameter)
    - `created` string, date-time, required — The timestamp the project logs event was created
    - `org_id` string, uuid, required — Unique id for the organization that the project belongs under
    - `project_id` string, uuid, required — Unique identifier for the project
    - `log_id` 'g', required — A literal 'g' which identifies the log as a project log
    - `input` unknown
    - `output` unknown
    - `expected` unknown
    - `error` unknown
    - `scores` object, nullable — A dictionary of numeric values (between 0 and 1) to log. The scores should give you a variety of signals that help you determine how accurate the outputs are compared to what you expect and diagnose failures. For example, a summarization app might have one score that tells you how accurate the summary is, and another that measures the word similarity between the generated and grouth truth summary. The word similarity score could help you determine whether the summarization was covering similar concepts or not. You can use these scores to help you sort, filter, and compare logs.
    - `metadata` object, nullable — A dictionary with additional data about the test example, model outputs, or just about anything else that's relevant, that you can use to help find and analyze examples later. For example, you could log the `prompt`, example's `id`, or anything else that would be useful to slice/dice later. The values in `metadata` can be any JSON-serializable type, but its keys must be strings
    - `tags` string[], nullable — A list of tags to log
    - `metrics` object, nullable — Metrics are numerical measurements tracking the execution of the code that produced the project logs event. Use "start" and "end" to track the time span over which the project logs event was produced
      - `start` number, nullable — A unix timestamp recording when the section of code which produced the project logs event started
      - `end` number, nullable — A unix timestamp recording when the section of code which produced the project logs event finished
      - `prompt_tokens` integer, nullable — The number of tokens in the prompt used to generate the project logs event (only set if this is an LLM span)
      - `completion_tokens` integer, nullable — The number of tokens in the completion generated by the model (only set if this is an LLM span)
      - `tokens` integer, nullable — The total number of tokens in the input and output of the project logs event.
    - `context` object, nullable — Context is additional information about the code that produced the project logs event. It is essentially the textual counterpart to `metrics`. Use the `caller_*` attributes to track the location in code which produced the project logs event
      - `caller_functionname` string, nullable — The function in code which created the project logs event
      - `caller_filename` string, nullable — Name of the file in code where the project logs event was created
      - `caller_lineno` integer, nullable — Line of code where the project logs event was created
    - `span_id` string, required — A unique identifier used to link different project logs events together as part of a full trace. See the [tracing guide](https://www.braintrust.dev/docs/guides/tracing) for full details on tracing
    - `span_parents` string[], nullable — An array of the parent `span_ids` of this project logs event. This should be empty for the root span of a trace, and should most often contain just one parent element for subspans
    - `root_span_id` string, required — The `span_id` of the root of the trace this project logs event belongs to
    - `span_attributes` object, nullable — Human-identifying attributes of the span, such as name, type, etc.
      - `name` string, nullable — Name of the span, for display purposes only
      - `type` 'llm' | 'score' | 'function' | 'eval' | 'task' | 'tool' | 'null', nullable — Type of the span, for display purposes only
  - `cursor` string, nullable — Pagination cursor Pass this string directly as the `cursor` param to your next fetch request to get the next page of results. Not provided if the returned result set is empty.

## Other responses

- `400` — The request was unacceptable, often due to missing a required parameter
- `401` — No valid API key provided
- `403` — The API key doesn’t have permissions to perform the request
- `429` — Too many requests hit the API too quickly. We recommend an exponential backoff of your requests
- `500` — Something went wrong on Braintrust's end. (These are rare.)

---

[API](https://skmtc.net/braintrustdata/apis/braintrust-api.md) · [All operations](https://skmtc.net/braintrustdata/apis/braintrust-api/llms.txt) · [OpenAPI document](https://skmtc-service-staging.skmtc.workers.dev/v1/apis/braintrustdata/braintrust-api/revisions/9d216c8243fe/schema)