Skip to main content
This is an interactive notebook. You can run it locally or use the links below:

Use the Service API to Log and Query Traces

In the following guide, you will learn how to use the Weave Service API to log traces. Specifically, you will use the Service API to:
  1. Create a mock of a simple LLM call and response, and log it to Weave.
  2. Create a mock of a more complex LLM call and response, and log it to Weave.
  3. Run a sample lookup query on the logged traces.
View logged traces You can view all of the Weave traces created when you run the code in this guide by going to the Traces tab in your Weave project (specified by team_id\project_id), and selecting the name of the trace.
Before beginning, complete the prerequisites

Prerequisites: Set variables and endpoints

The following code sets the URL endpoints that will be used to access the Service API: Additionally, you must set the following variables:
  • project_id: The name of the W&B project that you want to log your traces to.
  • team_id: Your W&B team name.
  • wandb_token: Your W&B authorization token.

Simple trace

The following sections walk you through creating a simple trace.
  1. Start a simple trace
  2. End a simple trace

Start a simple trace

The following code creates a sample LLM call payload_start and logs it to Weave using the url_start endpoint. The payload_start object mimics a call to OpenAI’s gpt-4o with the query Why is the sky blue?. On success, this code will output a message indicating that the trace was started:

End a simple trace

To complete the simple trace, the following code creates a sample LLM call payload_end and logs it to Weave using the url_end endpoint. The payload_end object mimics the response from OpenAI’s gpt-4o given the query Why is the sky blue?. The object is formatted so that pricing summary information and the chat completion are generated in trace view in the Weave Dashboard. On success, this code will output a message indicating that the trace completed:

Complex trace

The following sections walk you through creating a more complex trace with child spans, similar to a mult-operation RAG lookup.
  1. Start a complex trace
  2. Add a child span: RAG document lookup
  3. Add a child span: LLM completion call
  4. End a complex trace

Start a complex trace

The following code demonstrates how to create a more complex trace with multiple spans. An example of this would be a Retrieval-Augmented Generation (RAG) lookup followed by an LLM call. The first part initializes a parent trace(payload_parent_start) that represents the overall operation. In this case, the operation is processing the user query Can you summarize the key points of this document?. The payload_parent_start object mimics the initial step in a multi-step workflow, logging the the operation in Weave using the url_start endpoint. On success, this code will output a message indicating that the parent call was logged:

Add a child span to a complex trace: RAG document lookup

The following code demonstrates how to add a child span to the parent trace started in the previous step. This step models a the RAG document lookup sub-operation in the overarching workflow. The child trace is initiated with the payload_child_start object, which includes:
  • trace_id: Links this child span to the parent trace.
  • parent_id: Associates the child span with the parent operation.
  • inputs: Logs the search query, e.g., "This is a search query of the documents I'm looking for."
On a successful call to the url_start endpoint, the code outputs a message indicating that the child call was started and completed:

Add a child span to a complex trace: LLM completion call

The following code demonstrates how to add another child span to the parent trace, representing an LLM completion call. This step models the AI’s response generation based on document context retrieved in the previous RAG operation. The LLM completion trace is initiated with the payload_child_start object, which includes:
  • trace_id: Links this child span to the parent trace.
  • parent_id: Associates the child span with the overarching workflow.
  • inputs: Logs the input messages for the LLM, including the user query and the appended document context.
  • model: Specifies the model used for the operation (gpt-4o).
On success, the code outputs a message indicating the LLM child span trace has started and ended:
Once the operation completes, the payload_child_end object ends the trace by logging the LLM-generated response in the output field. Usage summary information is also logged. On success, the code outputs a message indicating the LLM child span trace has started and ended:

End a complex trace

The following code demonstrates how to finalize the parent trace, marking the completion of the entire workflow. This step aggregates the results of all child spans (e.g., RAG lookup and LLM completion) and logs the final output and metadata. The trace is finalized using the payload_parent_end object, which includes:
  • id: The parent_call_id from the initial parent trace start.
  • output: Represents the final output of the entire workflow.
  • summary: Consolidates usage data for the entire workflow.
  • prompt_tokens: Total tokens used for all prompts.
  • completion_tokens: Total tokens generated in all responses.
  • total_tokens: Combined token count for the workflow.
  • requests: Total number of requests made (in this case, 1).
On success, the code outputs:

Run a lookup query

The following code demonstrates how to query the traces created in previous examples, filtering only for traces where the inputs.model field is equal to gpt-4o. The query_payload object includes:
  • project_id: Identifies the team and project to query.
  • filter: Ensures the query returns only trace roots (top-level traces).
  • query: Defines the filter logic using the $expr operator:
    • $getField: Retrieves the inputs.model field.
    • $literal: Matches traces where inputs.model equals "gpt-4o".
  • limit: Limits the query to 10,000 results.
  • offset: Starts the query at the first result.
  • sort_by: Orders results by the started_at timestamp in descending order.
  • include_feedback: Excludes feedback data from the results.
On a successful query, the response will include trace data matching the query parameters: