Braintrust Logs API
The Logs API from Braintrust — 3 operation(s) for logs.
OpenAPI Specification
openapi: 3.1.1
info:
version: 1.0.0
title: Braintrust Acls Logs API
description: 'API specification for the backend data server. The API is hosted globally at
https://api.braintrust.dev or in your own environment.
You can access the OpenAPI spec for this API at https://github.com/braintrustdata/braintrust-openapi.'
license:
name: Apache 2.0
servers:
- url: https://api.braintrust.dev
security:
- bearerAuth: []
- {}
tags:
- name: Logs
paths:
/v1/project_logs/{project_id}/insert:
post:
operationId: postProjectLogsIdInsert
tags:
- Logs
description: Insert a set of events into the project logs
summary: Insert project logs events
security:
- bearerAuth: []
- {}
parameters:
- $ref: '#/components/parameters/ProjectIdParam'
requestBody:
description: An array of project logs events to insert
required: false
content:
application/json:
schema:
$ref: '#/components/schemas/InsertProjectLogsEventRequest'
responses:
'200':
description: Returns the inserted row ids
content:
application/json:
schema:
$ref: '#/components/schemas/InsertEventsResponse'
'400':
description: The request was unacceptable, often due to missing a required parameter
content:
text/plain:
schema:
type: string
application/json:
schema:
nullable: true
'401':
description: No valid API key provided
content:
text/plain:
schema:
type: string
application/json:
schema:
nullable: true
'403':
description: The API key doesn’t have permissions to perform the request
content:
text/plain:
schema:
type: string
application/json:
schema:
nullable: true
'429':
description: Too many requests hit the API too quickly. We recommend an exponential backoff of your requests
headers:
Retry-After:
schema:
type: string
content:
text/plain:
schema:
type: string
application/json:
schema:
nullable: true
'500':
description: Something went wrong on Braintrust's end. (These are rare.)
content:
text/plain:
schema:
type: string
application/json:
schema:
nullable: true
/v1/project_logs/{project_id}/fetch:
post:
operationId: postProjectLogsIdFetch
tags:
- Logs
description: 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. For more complex queries, use the `POST /btql` endpoint.
summary: Fetch project logs (POST form)
security:
- bearerAuth: []
- {}
parameters:
- $ref: '#/components/parameters/ProjectIdParam'
requestBody:
description: Filters for the fetch query
required: false
content:
application/json:
schema:
$ref: '#/components/schemas/FetchEventsRequest'
responses:
'200':
description: Returns the fetched rows
content:
application/json:
schema:
$ref: '#/components/schemas/FetchProjectLogsEventsResponse'
'400':
description: The request was unacceptable, often due to missing a required parameter
content:
text/plain:
schema:
type: string
application/json:
schema:
nullable: true
'401':
description: No valid API key provided
content:
text/plain:
schema:
type: string
application/json:
schema:
nullable: true
'403':
description: The API key doesn’t have permissions to perform the request
content:
text/plain:
schema:
type: string
application/json:
schema:
nullable: true
'429':
description: Too many requests hit the API too quickly. We recommend an exponential backoff of your requests
headers:
Retry-After:
schema:
type: string
content:
text/plain:
schema:
type: string
application/json:
schema:
nullable: true
'500':
description: Something went wrong on Braintrust's end. (These are rare.)
content:
text/plain:
schema:
type: string
application/json:
schema:
nullable: true
get:
operationId: getProjectLogsIdFetch
tags:
- Logs
description: Fetch the events in a project logs. Equivalent to the POST form of the same path, but with the parameters in the URL query rather than in the request body. For more complex queries, use the `POST /btql` endpoint.
summary: Fetch project logs (GET form)
security:
- bearerAuth: []
- {}
parameters:
- $ref: '#/components/parameters/ProjectIdParam'
- $ref: '#/components/parameters/FetchLimitParam'
- $ref: '#/components/parameters/MaxXactId'
- $ref: '#/components/parameters/MaxRootSpanId'
- $ref: '#/components/parameters/Version'
responses:
'200':
description: Returns the fetched rows
content:
application/json:
schema:
$ref: '#/components/schemas/FetchProjectLogsEventsResponse'
'400':
description: The request was unacceptable, often due to missing a required parameter
content:
text/plain:
schema:
type: string
application/json:
schema:
nullable: true
'401':
description: No valid API key provided
content:
text/plain:
schema:
type: string
application/json:
schema:
nullable: true
'403':
description: The API key doesn’t have permissions to perform the request
content:
text/plain:
schema:
type: string
application/json:
schema:
nullable: true
'429':
description: Too many requests hit the API too quickly. We recommend an exponential backoff of your requests
headers:
Retry-After:
schema:
type: string
content:
text/plain:
schema:
type: string
application/json:
schema:
nullable: true
'500':
description: Something went wrong on Braintrust's end. (These are rare.)
content:
text/plain:
schema:
type: string
application/json:
schema:
nullable: true
/v1/project_logs/{project_id}/feedback:
post:
operationId: postProjectLogsIdFeedback
tags:
- Logs
description: Log feedback for a set of project logs events
summary: Feedback for project logs events
security:
- bearerAuth: []
- {}
parameters:
- $ref: '#/components/parameters/ProjectIdParam'
requestBody:
description: An array of feedback objects
required: false
content:
application/json:
schema:
$ref: '#/components/schemas/FeedbackProjectLogsEventRequest'
responses:
'200':
description: Returns a success status
content:
application/json:
schema:
$ref: '#/components/schemas/FeedbackResponseSchema'
'400':
description: The request was unacceptable, often due to missing a required parameter
content:
text/plain:
schema:
type: string
application/json:
schema:
nullable: true
'401':
description: No valid API key provided
content:
text/plain:
schema:
type: string
application/json:
schema:
nullable: true
'403':
description: The API key doesn’t have permissions to perform the request
content:
text/plain:
schema:
type: string
application/json:
schema:
nullable: true
'429':
description: Too many requests hit the API too quickly. We recommend an exponential backoff of your requests
headers:
Retry-After:
schema:
type: string
content:
text/plain:
schema:
type: string
application/json:
schema:
nullable: true
'500':
description: Something went wrong on Braintrust's end. (These are rare.)
content:
text/plain:
schema:
type: string
application/json:
schema:
nullable: true
components:
schemas:
InsertProjectLogsEvent:
type: object
properties:
input:
nullable: true
description: The arguments that uniquely define a user input (an arbitrary, JSON serializable object).
output:
nullable: true
description: The output of your application, including post-processing (an arbitrary, JSON serializable object), that allows you to determine whether the result is correct or not. For example, in an app that generates SQL queries, the `output` should be the _result_ of the SQL query generated by the model, not the query itself, because there may be multiple valid queries that answer a single question.
expected:
nullable: true
description: The ground truth value (an arbitrary, JSON serializable object) that you'd compare to `output` to determine if your `output` value is correct or not. Braintrust currently does not compare `output` to `expected` for you, since there are so many different ways to do that correctly. Instead, these values are just used to help you navigate while digging into analyses. However, we may later use these values to re-score outputs or fine-tune your models.
error:
nullable: true
description: The error that occurred, if any.
scores:
type: object
nullable: true
additionalProperties:
type: number
nullable: true
minimum: 0
maximum: 1
description: 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:
type: object
nullable: true
properties:
model:
type: string
nullable: true
description: The model used for this example
additionalProperties:
nullable: true
description: 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:
type: array
nullable: true
items:
type: string
description: A list of tags to log
metrics:
type: object
nullable: true
properties:
start:
type: number
nullable: true
description: A unix timestamp recording when the section of code which produced the project logs event started
end:
type: number
nullable: true
description: A unix timestamp recording when the section of code which produced the project logs event finished
prompt_tokens:
type: integer
nullable: true
description: The number of tokens in the prompt used to generate the project logs event (only set if this is an LLM span)
completion_tokens:
type: integer
nullable: true
description: The number of tokens in the completion generated by the model (only set if this is an LLM span)
tokens:
type: integer
nullable: true
description: The total number of tokens in the input and output of the project logs event.
caller_functionname:
nullable: true
description: This metric is deprecated
caller_filename:
nullable: true
description: This metric is deprecated
caller_lineno:
nullable: true
description: This metric is deprecated
additionalProperties:
type: number
description: 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
context:
type: object
nullable: true
properties:
caller_functionname:
type: string
nullable: true
description: The function in code which created the project logs event
caller_filename:
type: string
nullable: true
description: Name of the file in code where the project logs event was created
caller_lineno:
type: integer
nullable: true
description: Line of code where the project logs event was created
additionalProperties:
nullable: true
description: 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
span_attributes:
$ref: '#/components/schemas/SpanAttributes'
id:
type: string
nullable: true
description: A unique identifier for the project logs event. If you don't provide one, Braintrust will generate one for you
created:
type: string
nullable: true
format: date-time
description: The timestamp the project logs event was created
origin:
$ref: '#/components/schemas/ObjectReferenceNullish'
facets:
type: object
nullable: true
additionalProperties:
nullable: true
description: Facets for categorization (dictionary from facet id to value)
_object_delete:
type: boolean
nullable: true
description: Pass `_object_delete=true` to mark the project logs event deleted. Deleted events will not show up in subsequent fetches for this project logs
_is_merge:
type: boolean
nullable: true
description: 'The `_is_merge` field controls how the row is merged with any existing row with the same id in the DB. By default (or when set to `false`), the existing row is completely replaced by the new row. When set to `true`, the new row is deep-merged into the existing row, if one is found. If no existing row is found, the new row is inserted as is.
For example, say there is an existing row in the DB `{"id": "foo", "input": {"a": 5, "b": 10}}`. If we merge a new row as `{"_is_merge": true, "id": "foo", "input": {"b": 11, "c": 20}}`, the new row will be `{"id": "foo", "input": {"a": 5, "b": 11, "c": 20}}`. If we replace the new row as `{"id": "foo", "input": {"b": 11, "c": 20}}`, the new row will be `{"id": "foo", "input": {"b": 11, "c": 20}}`'
_merge_paths:
type: array
nullable: true
items:
type: array
items:
type: string
description: 'The `_merge_paths` field allows controlling the depth of the merge, when `_is_merge=true`. `_merge_paths` is a list of paths, where each path is a list of field names. The deep merge will not descend below any of the specified merge paths.
For example, say there is an existing row in the DB `{"id": "foo", "input": {"a": {"b": 10}, "c": {"d": 20}}, "output": {"a": 20}}`. If we merge a new row as `{"_is_merge": true, "_merge_paths": [["input", "a"], ["output"]], "input": {"a": {"q": 30}, "c": {"e": 30}, "bar": "baz"}, "output": {"d": 40}}`, the new row will be `{"id": "foo": "input": {"a": {"q": 30}, "c": {"d": 20, "e": 30}, "bar": "baz"}, "output": {"d": 40}}`. In this case, due to the merge paths, we have replaced `input.a` and `output`, but have still deep-merged `input` and `input.c`.'
_array_delete:
type: array
nullable: true
items:
type: object
properties:
path:
type: array
items:
type: string
delete:
type: array
items:
nullable: true
required:
- path
- delete
description: 'The `_array_delete` field allows removing specific values from array fields. It is an array of objects with `path` and `delete` properties.
For example, to remove tags "foo" and "bar" from an existing row: `{"_is_merge": true, "_array_delete": [{"path": ["tags"], "delete": ["foo", "bar"]}]}`. For nested fields like `metadata.categories`, use `[{"path": ["metadata", "categories"], "delete": ["value"]}]`. This will remove those specific values from the array while preserving others.'
_parent_id:
type: string
nullable: true
description: 'DEPRECATED: The `_parent_id` field is deprecated and should not be used. Support for `_parent_id` will be dropped in a future version of Braintrust. Log `span_id`, `root_span_id`, and `span_parents` explicitly instead.
Use the `_parent_id` field to create this row as a subspan of an existing row. Tracking hierarchical relationships are important for tracing (see the [guide](https://www.braintrust.dev/docs/instrument) for full details).
For example, say we have logged a row `{"id": "abc", "input": "foo", "output": "bar", "expected": "boo", "scores": {"correctness": 0.33}}`. We can create a sub-span of the parent row by logging `{"_parent_id": "abc", "id": "llm_call", "input": {"prompt": "What comes after foo?"}, "output": "bar", "metrics": {"tokens": 1}}`. In the webapp, only the root span row `"abc"` will show up in the summary view. You can view the full trace hierarchy (in this case, the `"llm_call"` row) by clicking on the "abc" row.
If the row is being merged into an existing row, this field will be ignored.'
span_id:
type: string
nullable: true
description: 'Use `span_id`, `root_span_id`, and `span_parents` instead of `_parent_id`, which is now deprecated. The span_id is a unique identifier describing the row''s place in the a trace, and the root_span_id is a unique identifier for the whole trace. See the [guide](https://www.braintrust.dev/docs/instrument) for full details.
For example, say we have logged a row `{"id": "abc", "span_id": "span0", "root_span_id": "root_span0", "input": "foo", "output": "bar", "expected": "boo", "scores": {"correctness": 0.33}}`. We can create a sub-span of the parent row by logging `{"id": "llm_call", "span_id": "span1", "root_span_id": "root_span0", "span_parents": ["span0"], "input": {"prompt": "What comes after foo?"}, "output": "bar", "metrics": {"tokens": 1}}`. In the webapp, only the root span row `"abc"` will show up in the summary view. You can view the full trace hierarchy (in this case, the `"llm_call"` row) by clicking on the "abc" row.
If the row is being merged into an existing row, this field will be ignored.'
root_span_id:
type: string
nullable: true
description: 'Use `span_id`, `root_span_id`, and `span_parents` instead of `_parent_id`, which is now deprecated. The span_id is a unique identifier describing the row''s place in the a trace, and the root_span_id is a unique identifier for the whole trace. See the [guide](https://www.braintrust.dev/docs/instrument) for full details.
For example, say we have logged a row `{"id": "abc", "span_id": "span0", "root_span_id": "root_span0", "input": "foo", "output": "bar", "expected": "boo", "scores": {"correctness": 0.33}}`. We can create a sub-span of the parent row by logging `{"id": "llm_call", "span_id": "span1", "root_span_id": "root_span0", "span_parents": ["span0"], "input": {"prompt": "What comes after foo?"}, "output": "bar", "metrics": {"tokens": 1}}`. In the webapp, only the root span row `"abc"` will show up in the summary view. You can view the full trace hierarchy (in this case, the `"llm_call"` row) by clicking on the "abc" row.
If the row is being merged into an existing row, this field will be ignored.'
span_parents:
type: array
nullable: true
items:
type: string
description: 'Use `span_id`, `root_span_id`, and `span_parents` instead of `_parent_id`, which is now deprecated. The span_id is a unique identifier describing the row''s place in the a trace, and the root_span_id is a unique identifier for the whole trace. See the [guide](https://www.braintrust.dev/docs/instrument) for full details.
For example, say we have logged a row `{"id": "abc", "span_id": "span0", "root_span_id": "root_span0", "input": "foo", "output": "bar", "expected": "boo", "scores": {"correctness": 0.33}}`. We can create a sub-span of the parent row by logging `{"id": "llm_call", "span_id": "span1", "root_span_id": "root_span0", "span_parents": ["span0"], "input": {"prompt": "What comes after foo?"}, "output": "bar", "metrics": {"tokens": 1}}`. In the webapp, only the root span row `"abc"` will show up in the summary view. You can view the full trace hierarchy (in this case, the `"llm_call"` row) by clicking on the "abc" row.
If the row is being merged into an existing row, this field will be ignored.'
description: A project logs event
FetchEventsRequest:
type: object
properties:
limit:
$ref: '#/components/schemas/FetchLimit'
cursor:
$ref: '#/components/schemas/FetchPaginationCursor'
max_xact_id:
$ref: '#/components/schemas/MaxXactId'
nullable: true
max_root_span_id:
$ref: '#/components/schemas/MaxRootSpanId'
nullable: true
version:
$ref: '#/components/schemas/Version'
nullable: true
InsertProjectLogsEventRequest:
type: object
properties:
events:
type: array
items:
$ref: '#/components/schemas/InsertProjectLogsEvent'
description: A list of project logs events to insert
required:
- events
FetchPaginationCursor:
type: string
nullable: true
description: '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'
FeedbackResponseSchema:
type: object
properties:
status:
type: string
enum:
- success
required:
- status
FetchLimit:
type: integer
nullable: true
minimum: 0
description: '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.'
FetchLimitParam:
type: integer
nullable: true
minimum: 0
description: '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.'
MaxRootSpanId:
type: string
description: '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.'
ProjectLogsEvent:
type: object
properties:
id:
type: string
description: A unique identifier for the project logs event. If you don't provide one, Braintrust will generate one for you
_xact_id:
type: string
description: 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)
_pagination_key:
type: string
nullable: true
description: A stable, time-ordered key that can be used to paginate over project logs events. This field is auto-generated by Braintrust and only exists in Brainstore.
created:
type: string
format: date-time
description: The timestamp the project logs event was created
org_id:
type: string
format: uuid
description: Unique id for the organization that the project belongs under
project_id:
type: string
format: uuid
description: Unique identifier for the project
log_id:
type: string
enum:
- g
description: A literal 'g' which identifies the log as a project log
input:
nullable: true
description: The arguments that uniquely define a user input (an arbitrary, JSON serializable object).
output:
nullable: true
description: The output of your application, including post-processing (an arbitrary, JSON serializable object), that allows you to determine whether the result is correct or not. For example, in an app that generates SQL queries, the `output` should be the _result_ of the SQL query generated by the model, not the query itself, because there may be multiple valid queries that answer a single question.
expected:
nullable: true
description: The ground truth value (an arbitrary, JSON serializable object) that you'd compare to `output` to determine if your `output` value is correct or not. Braintrust currently does not compare `output` to `expected` for you, since there are so many different ways to do that correctly. Instead, these values are just used to help you navigate while digging into analyses. However, we may later use these values to re-score outputs or fine-tune your models.
error:
nullable: true
description: The error that occurred, if any.
scores:
type: object
nullable: true
additionalProperties:
type: number
nullable: true
minimum: 0
maximum: 1
description: 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:
type: object
nullable: true
properties:
model:
type: string
nullable: true
description: The model used for this example
additionalProperties:
nullable: true
description: 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:
type: array
nullable: true
items:
type: string
description: A list of tags to log
metrics:
type: object
nullable: true
properties:
start:
type: number
nullable: true
description: A unix timestamp recording when the section of code which produced the project logs event started
end:
type: number
nullable: true
description: A unix timestamp recording when the section of code which produced the project logs event finished
prompt_tokens:
type: integer
nullable: true
description: The number of tokens in the prompt used to generate the project logs event (only set if this is an LLM span)
completion_tokens:
type: integer
nullable: true
description: The number of tokens in the completion generated by the model (only set if this is an LLM span)
tokens:
type: integer
nullable: true
# --- truncated at 32 KB (46 KB total) ---
# Full source: https://raw.githubusercontent.com/api-evangelist/braintrust/refs/heads/main/openapi/braintrust-logs-api-openapi.yml