--- title: "Insert experiment events" method: POST path: "/v1/experiment/{experiment_id}/insert" tags: ["Experiments"] --- # Insert experiment events `POST /v1/experiment/{experiment_id}/insert` Insert a set of events into the experiment ## Path parameters - `experiment_id` string, uuid, required — Experiment id ## Request body - InsertExperimentEventRequest - `events` InsertExperimentEvent[], required — A list of experiment events to insert - union — An experiment event - InsertExperimentEventReplace - `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 experiments - `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 experiment event. Use "start" and "end" to track the time span over which the experiment event was produced - `start` number, nullable — A unix timestamp recording when the section of code which produced the experiment event started - `end` number, nullable — A unix timestamp recording when the section of code which produced the experiment event finished - `prompt_tokens` integer, nullable — The number of tokens in the prompt used to generate the experiment 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 experiment event. - `context` object, nullable — 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 - `caller_functionname` string, nullable — The function in code which created the experiment event - `caller_filename` string, nullable — Name of the file in code where the experiment event was created - `caller_lineno` integer, nullable — Line of code where the experiment event was created - `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 - `id` string, nullable — A unique identifier for the experiment event. If you don't provide one, BrainTrust will generate one for you - `dataset_record_id` string, nullable — If the experiment is associated to a dataset, this is the event-level dataset id this experiment event is tied to - `created` string, date-time, nullable — The timestamp the experiment event was created - `_object_delete` boolean, nullable — Pass `_object_delete=true` to mark the experiment event deleted. Deleted events will not show up in subsequent fetches for this experiment - `_is_merge` boolean, nullable — 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 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}}` - `_parent_id` string, nullable — Use the `_parent_id` field to create this row as a subspan of an existing row. It cannot be specified alongside `_is_merge=true`. Tracking hierarchical relationships are important for tracing (see the [guide](https://www.braintrust.dev/docs/guides/tracing) 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. - InsertExperimentEventMerge - `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 experiments - `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 experiment event. Use "start" and "end" to track the time span over which the experiment event was produced - `start` number, nullable — A unix timestamp recording when the section of code which produced the experiment event started - `end` number, nullable — A unix timestamp recording when the section of code which produced the experiment event finished - `prompt_tokens` integer, nullable — The number of tokens in the prompt used to generate the experiment 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 experiment event. - `context` object, nullable — 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 - `caller_functionname` string, nullable — The function in code which created the experiment event - `caller_filename` string, nullable — Name of the file in code where the experiment event was created - `caller_lineno` integer, nullable — Line of code where the experiment event was created - `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 - `id` string, nullable — A unique identifier for the experiment event. If you don't provide one, BrainTrust will generate one for you - `dataset_record_id` string, nullable — If the experiment is associated to a dataset, this is the event-level dataset id this experiment event is tied to - `created` string, date-time, nullable — The timestamp the experiment event was created - `_object_delete` boolean, nullable — Pass `_object_delete=true` to mark the experiment event deleted. Deleted events will not show up in subsequent fetches for this experiment - `_is_merge` boolean, required — 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 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` array[], nullable — The `_merge_paths` field allows controlling the depth of the merge. It can only be specified alongside `_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`. - string[] ## Response `200` Returns the inserted row ids - InsertEventsResponse - `row_ids` string[], required — The ids of all rows that were inserted, aligning one-to-one with the rows provided as input ## 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)