> ## Documentation Index
> Fetch the complete documentation index at: https://braintrust.dev/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Insert project logs events

> Insert a set of events into the project logs



## OpenAPI

````yaml /openapi.yaml post /v1/project_logs/{project_id}/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/project_logs/{project_id}/insert:
    post:
      tags:
        - Logs
      summary: Insert project logs events
      description: Insert a set of events into the project logs
      operationId: postProjectLogsIdInsert
      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
      security:
        - bearerAuth: []
        - {}
components:
  parameters:
    ProjectIdParam:
      schema:
        $ref: '#/components/schemas/ProjectIdParam'
      required: true
      description: Project id
      name: project_id
      in: path
  schemas:
    InsertProjectLogsEventRequest:
      type: object
      properties:
        events:
          type: array
          items:
            $ref: '#/components/schemas/InsertProjectLogsEvent'
          description: A list of project logs events to insert
      required:
        - events
    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
    ProjectIdParam:
      type: string
      format: uuid
      description: Project id
    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:
            type: string
            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
    SpanAttributes:
      type: object
      nullable: true
      properties:
        name:
          type: string
          nullable: true
          description: Name of the span, for display purposes only
        type:
          $ref: '#/components/schemas/SpanType'
        purpose:
          type: string
          nullable: true
          enum:
            - scorer
            - null
          description: >-
            A special value that indicates the span was generated by a scoring
            automation
      additionalProperties:
        nullable: true
      description: Human-identifying attributes of the span, such as name, type, etc.
    ObjectReferenceNullish:
      type: object
      nullable: true
      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
          nullable: true
          description: Transaction ID of the original event.
        created:
          type: string
          nullable: true
          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
      nullable: true
      enum:
        - llm
        - score
        - function
        - eval
        - task
        - tool
        - automation
        - facet
        - preprocessor
        - classifier
        - review
        - 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).

````