> ## Documentation Index > Fetch the complete documentation index at: https://docs.braintrust.dev/llms.txt > Use this file to discover all available pages before exploring further. # Cross-object insert > Insert events and feedback across object types ## OpenAPI ````yaml /openapi.yaml post /v1/insert openapi: 3.1.1 info: version: 1.0.0 title: Braintrust 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: [] - {} paths: /v1/insert: post: tags: - CrossObject summary: Cross-object insert description: Insert events and feedback across object types operationId: postCrossObjectInsert requestBody: description: A mapping from event object type -> object id -> events to insert required: false content: application/json: schema: $ref: '#/components/schemas/CrossObjectInsertRequest' responses: '200': description: >- Returns the inserted row ids for the events on each individual object content: application/json: schema: $ref: '#/components/schemas/CrossObjectInsertResponse' '400': description: >- The request was unacceptable, often due to missing a required parameter content: text/plain: schema: type: string application/json: schema: {} '401': description: No valid API key provided content: text/plain: schema: type: string application/json: schema: {} '403': description: The API key doesn’t have permissions to perform the request content: text/plain: schema: type: string application/json: schema: {} '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: {} '500': description: Something went wrong on Braintrust's end. (These are rare.) content: text/plain: schema: type: string application/json: schema: {} security: - bearerAuth: [] components: schemas: CrossObjectInsertRequest: type: object properties: experiment: type: - object - 'null' additionalProperties: type: object properties: events: type: - array - 'null' items: $ref: '#/components/schemas/InsertExperimentEvent' description: A list of experiment events to insert feedback: type: - array - 'null' items: $ref: '#/components/schemas/FeedbackExperimentItem' description: A list of experiment feedback items description: >- A mapping from experiment id to a set of log events and feedback items to insert dataset: type: - object - 'null' additionalProperties: type: object properties: events: type: - array - 'null' items: $ref: '#/components/schemas/InsertDatasetEvent' description: A list of dataset events to insert feedback: type: - array - 'null' items: $ref: '#/components/schemas/FeedbackDatasetItem' description: A list of dataset feedback items description: >- A mapping from dataset id to a set of log events and feedback items to insert project_logs: type: - object - 'null' additionalProperties: type: object properties: events: type: - array - 'null' items: $ref: '#/components/schemas/InsertProjectLogsEvent' description: A list of project logs events to insert feedback: type: - array - 'null' items: $ref: '#/components/schemas/FeedbackProjectLogsItem' description: A list of project logs feedback items description: >- A mapping from project id to a set of log events and feedback items to insert CrossObjectInsertResponse: type: object properties: experiment: type: - object - 'null' additionalProperties: $ref: '#/components/schemas/InsertEventsResponse' description: A mapping from experiment id to row ids for inserted `events` dataset: type: - object - 'null' additionalProperties: $ref: '#/components/schemas/InsertEventsResponse' description: A mapping from dataset id to row ids for inserted `events` project_logs: type: - object - 'null' additionalProperties: $ref: '#/components/schemas/InsertEventsResponse' description: A mapping from project id to row ids for inserted `events` InsertExperimentEvent: type: object properties: input: description: >- The arguments that uniquely define a test case (an arbitrary, JSON serializable object). Later on, Braintrust will use the `input` to know whether two test cases are the same between experiments, so they should not contain experiment-specific state. A simple rule of thumb is that if you run the same experiment twice, the `input` should be identical output: 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: 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 your experiments while digging into analyses. However, we may later use these values to re-score outputs or fine-tune your models error: description: The error that occurred, if any. scores: type: - object - 'null' additionalProperties: type: - number - 'null' 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 experiments metadata: type: - object - 'null' properties: model: type: - string - 'null' description: The model used for this example additionalProperties: {} 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 - 'null' items: type: string description: A list of tags to log metrics: type: - object - 'null' properties: start: type: - number - 'null' description: >- A unix timestamp recording when the section of code which produced the experiment event started end: type: - number - 'null' description: >- A unix timestamp recording when the section of code which produced the experiment event finished prompt_tokens: type: - integer - 'null' description: >- The number of tokens in the prompt used to generate the experiment event (only set if this is an LLM span) completion_tokens: type: - integer - 'null' description: >- The number of tokens in the completion generated by the model (only set if this is an LLM span) tokens: type: - integer - 'null' description: >- The total number of tokens in the input and output of the experiment event. caller_functionname: description: Deprecated. Use `context.caller_functionname` instead. caller_filename: description: Deprecated. Use `context.caller_filename` instead. caller_lineno: description: Deprecated. Use `context.caller_lineno` instead. additionalProperties: type: number description: >- Metrics are numerical measurements tracking the execution of the code that produced the experiment event. Use "start" and "end" to track the time span over which the experiment event was produced context: type: - object - 'null' properties: caller_functionname: type: - string - 'null' description: The function in code which created the experiment event caller_filename: type: - string - 'null' description: Name of the file in code where the experiment event was created caller_lineno: type: - integer - 'null' description: Line of code where the experiment event was created additionalProperties: {} description: >- Context is additional information about the code that produced the experiment event. It is essentially the textual counterpart to `metrics`. Use the `caller_*` attributes to track the location in code which produced the experiment event span_attributes: $ref: '#/components/schemas/SpanAttributes' id: type: - string - 'null' description: >- A unique identifier for the experiment event. If you don't provide one, Braintrust will generate one for you created: type: - string - 'null' format: date-time description: The timestamp the experiment event was created origin: $ref: '#/components/schemas/ObjectReferenceNullish' facets: type: - object - 'null' additionalProperties: type: - string - 'null' description: Facets for categorization (dictionary from facet id to value) _object_delete: type: - boolean - 'null' description: >- Pass `_object_delete=true` to mark the experiment event deleted. Deleted events will not show up in subsequent fetches for this experiment _is_merge: type: - boolean - 'null' 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 - 'null' 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 - 'null' items: type: object properties: path: type: array items: type: string delete: type: array items: {} 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 - 'null' 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://docs.braintrust.dev/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 - 'null' 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://docs.braintrust.dev/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 - 'null' 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://docs.braintrust.dev/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 - 'null' 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://docs.braintrust.dev/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: An experiment event FeedbackExperimentItem: type: object properties: id: type: string description: >- The id of the experiment event to log feedback for. This is the row `id` returned by `POST /v1/experiment/{experiment_id}/insert` scores: type: - object - 'null' additionalProperties: type: - number - 'null' minimum: 0 maximum: 1 description: >- A dictionary of numeric values (between 0 and 1) to log. These scores will be merged into the existing scores for the experiment event expected: 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 comment: type: - string - 'null' description: An optional comment string to log about the experiment event metadata: type: - object - 'null' additionalProperties: {} description: >- A dictionary with additional data about the feedback. If you have a `user_id`, you can log it here and access it in the Braintrust UI. Note, this metadata does not correspond to the main event itself, but rather the audit log attached to the event. source: type: - string - 'null' enum: - app - api - external - null description: >- The source of the feedback. Must be one of "external" (default), "app", or "api" tags: type: - array - 'null' items: type: string description: A list of tags to log required: - id InsertDatasetEvent: type: object properties: input: description: >- The argument that uniquely define an input case (an arbitrary, JSON serializable object) expected: description: >- The output of your application, including post-processing (an arbitrary, JSON serializable object) metadata: type: - object - 'null' properties: model: type: - string - 'null' description: The model used for this example additionalProperties: {} 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 - 'null' items: type: string description: A list of tags to log id: type: - string - 'null' description: >- A unique identifier for the dataset event. If you don't provide one, Braintrust will generate one for you created: type: - string - 'null' format: date-time description: The timestamp the dataset event was created origin: $ref: '#/components/schemas/ObjectReferenceNullish' facets: type: - object - 'null' additionalProperties: type: - string - 'null' description: Facets for categorization (dictionary from facet id to value) _object_delete: type: - boolean - 'null' description: >- Pass `_object_delete=true` to mark the dataset event deleted. Deleted events will not show up in subsequent fetches for this dataset _is_merge: type: - boolean - 'null' 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 - 'null' 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 - 'null' items: type: object properties: path: type: array items: type: string delete: type: array items: {} 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 - 'null' 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://docs.braintrust.dev/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 - 'null' 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://docs.braintrust.dev/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 - 'null' 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://docs.braintrust.dev/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 - 'null' 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://docs.braintrust.dev/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 dataset event FeedbackDatasetItem: type: object properties: id: type: string description: >- The id of the dataset event to log feedback for. This is the row `id` returned by `POST /v1/dataset/{dataset_id}/insert` comment: type: - string - 'null' description: An optional comment string to log about the dataset event metadata: type: - object - 'null' additionalProperties: {} description: >- A dictionary with additional data about the feedback. If you have a `user_id`, you can log it here and access it in the Braintrust UI. Note, this metadata does not correspond to the main event itself, but rather the audit log attached to the event. source: type: - string - 'null' enum: - app - api - external - null description: >- The source of the feedback. Must be one of "external" (default), "app", or "api" tags: type: - array - 'null' items: type: string description: A list of tags to log required: - id InsertProjectLogsEvent: type: object properties: input: description: >- The arguments that uniquely define a user input (an arbitrary, JSON serializable object). output: 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: 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: description: The error that occurred, if any. scores: type: - object - 'null' additionalProperties: type: - number - 'null' 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 - 'null' properties: model: type: - string - 'null' description: The model used for this example additionalProperties: {} 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 - 'null' items: type: string description: A list of tags to log metrics: type: - object - 'null' properties: start: type: - number - 'null' description: >- A unix timestamp recording when the section of code which produced the project logs event started end: type: - number - 'null' description: >- A unix timestamp recording when the section of code which produced the project logs event finished prompt_tokens: type: - integer - 'null' 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 - 'null' description: >- The number of tokens in the completion generated by the model (only set if this is an LLM span) tokens: type: - integer - 'null' description: >- The total number of tokens in the input and output of the project logs event. caller_functionname: description: Deprecated. Use `context.caller_functionname` instead. caller_filename: description: Deprecated. Use `context.caller_filename` instead. caller_lineno: description: Deprecated. Use `context.caller_lineno` instead. 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 - 'null' properties: caller_functionname: type: - string - 'null' description: The function in code which created the project logs event caller_filename: type: - string - 'null' description: >- Name of the file in code where the project logs event was created caller_lineno: type: - integer - 'null' description: Line of code where the project logs event was created additionalProperties: {} 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 - 'null' description: >- A unique identifier for the project logs event. If you don't provide one, Braintrust will generate one for you created: type: - string - 'null' format: date-time description: The timestamp the project logs event was created origin: $ref: '#/components/schemas/ObjectReferenceNullish' facets: type: - object - 'null' additionalProperties: type: - string - 'null' description: Facets for categorization (dictionary from facet id to value) _object_delete: type: - boolean - 'null' 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 - 'null' 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 - 'null' 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 - 'null' items: type: object properties: path: type: array items: type: string delete: type: array items: {} 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 - 'null' 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://docs.braintrust.dev/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 - 'null' 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://docs.braintrust.dev/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 - 'null' 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://docs.braintrust.dev/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 - 'null' 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://docs.braintrust.dev/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 FeedbackProjectLogsItem: type: object properties: id: type: string description: >- The id of the project logs event to log feedback for. This is the row `id` returned by `POST /v1/project_logs/{project_id}/insert` scores: type: - object - 'null' additionalProperties: type: - number - 'null' minimum: 0 maximum: 1 description: >- A dictionary of numeric values (between 0 and 1) to log. These scores will be merged into the existing scores for the project logs event expected: 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 comment: type: - string - 'null' description: An optional comment string to log about the project logs event metadata: type: - object - 'null' additionalProperties: {} description: >- A dictionary with additional data about the feedback. If you have a `user_id`, you can log it here and access it in the Braintrust UI. Note, this metadata does not correspond to the main event itself, but rather the audit log attached to the event. source: type: - string - 'null' enum: - app - api - external - null description: >- The source of the feedback. Must be one of "external" (default), "app", or "api" tags: type: - array - 'null' items: type: string description: A list of tags to log required: - id InsertEventsResponse: type: object properties: row_ids: type: array items: type: string description: >- The ids of all rows that were inserted, aligning one-to-one with the rows provided as input required: - row_ids SpanAttributes: type: - object - 'null' properties: name: type: - string - 'null' description: Name of the span, for display purposes only type: $ref: '#/components/schemas/SpanType' purpose: type: - string - 'null' enum: - scorer - null description: >- A special value that indicates the span was generated by a scoring automation log_level: type: - string - 'null' enum: - trace - debug - info - warn - error - fatal - null description: Severity level of a log additionalProperties: {} description: Human-identifying attributes of the span, such as name, type, etc. ObjectReferenceNullish: type: - object - 'null' properties: object_type: type: string enum: - project_logs - experiment - dataset - prompt - function - prompt_session description: Type of the object the event is originating from. object_id: type: string format: uuid description: ID of the object the event is originating from. id: type: string description: ID of the original event. _xact_id: type: - string - 'null' description: Transaction ID of the original event. created: type: - string - 'null' description: Created timestamp of the original event. Used to help sort in the UI required: - object_type - object_id - id description: Indicates the event was copied from another object. SpanType: type: - string - 'null' enum: - llm - score - function - eval - task - tool - automation - facet - preprocessor - classifier - review - decision - question - log - null description: Type of the span, for display purposes only securitySchemes: bearerAuth: type: http scheme: bearer bearerFormat: API key or JWT description: >- Most Braintrust endpoints are authenticated by providing your API key as a header `Authorization: Bearer [api_key]` to your HTTP request. You can create an API key in the Braintrust [organization settings page](https://www.braintrustdata.com/app/settings?subroute=api-keys). ```` This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.