Skip to main content
The honeyhive-logger package is a lightweight API wrapper with start(), log(), and update() functions. The v1 honeyhive package adds OpenTelemetry tracing, automatic context propagation, decorators, instrumentors, and evaluation support. Use this guide when moving Python code from honeyhive-logger to honeyhive>=1.0.0.
The logger package is useful when you need a dependency-free client. Migrate to the v1 SDK when you want automatic spans, nested trace trees, framework integrations, or evaluate().

API mapping


1. Replace the package

Set credentials:
You no longer need to set HH_PROJECT or pass project= to HoneyHiveTracer.init(). HoneyHive API keys are project-scoped — the API key alone determines which project traces are routed to. Drop HH_PROJECT and project= anywhere they are set in logger code; neither has any effect on the API or SDK behavior. Passing project= explicitly to HoneyHiveTracer.init(...) emits a DeprecationWarning because the kwarg will be removed in v2.0. The examples below use HoneyHiveTracer.init() with no kwargs.

2. Migrate session creation

Logger code usually starts a session and passes session_id to every event. In v1, initialize a tracer once and use session helpers to scope work.
For async frameworks (FastAPI, async Flask), use await tracer.acreate_session(...) — same arguments as create_session().
Unlike the logger, the v1 SDK can serve concurrent requests safely from a single shared tracer because create_session() / acreate_session() / with_session() store the session ID in OpenTelemetry baggage (ContextVar-based) rather than on the tracer instance. See Tracer Initialization for FastAPI, Flask, and Lambda patterns.
For single-operation scripts, with_session() keeps session setup close to the work:

3. Replace log() with @trace

Use @trace when the event maps to a Python function.
The decorator captures function inputs and outputs automatically. Use tracer.enrich_span(...) inside the function for extra metadata, metrics, feedback, config, or a custom output shape.

4. Replace log() with manual spans when decorators do not fit

Use enrich_span_context() for loops, conditional blocks, or code that is not cleanly wrapped by a function.
In honeyhive>=1.0.0, enrich_span_context is not re-exported at honeyhive or honeyhive.tracer. Import it from honeyhive.tracer.processing.context. Always pass tracer_instance=tracer — otherwise the helper falls back to an unconfigured OpenTelemetry tracer and spans will not reach HoneyHive. enrich_span_context does not expose an event_type parameter; set it via the raw attributes={"honeyhive_event_type": "tool"} attribute when migrating a log(event_type=...) call.
Use tracer.start_span() only when you need raw OpenTelemetry control:

5. Replace update() for events

When you need to update a known event ID, pass it to tracer.enrich_span().
Use event_id when you want to update an existing event in HoneyHive. If you are updating the current active span, omit event_id.
Getting an event_id back. The @trace decorator and enrich_span_context() do not return event IDs — they manage span IDs through OpenTelemetry context. If you need the same “create event, hold on to its ID, update it later” pattern as the logger, use the lower-level tracer.create_event(...) method, which posts the event directly via the events API and returns its ID.
There is also an update_event_id parameter on tracer.enrich_span(...) that lets you tag the current span with a client-supplied UUID and later look that event up with enrich_span(event_id=...), but the round-trip depends on backend behavior we have not validated end-to-end — prefer the create_event path above unless you have already confirmed the UUID flow against your HoneyHive deployment.
If the event is the current active span, omit event_id:

6. Replace update() for sessions

Logger uses update(event_id=session_id, ...) for session updates. In v1, use session enrichment.
If you created the session with create_session() in the active request, you can omit session_id:

7. Add automatic provider instrumentation

After migrating logger calls, you can add automatic model or framework spans.
Initialize the tracer before any instrumentor, and call instrument() before constructing your provider client (for example, openai.OpenAI()). See Integrations for provider-specific setup.

Complete before and after

Flush before process exit in short-lived scripts. Unlike honeyhive-logger, which sends each call synchronously, the v1 SDK batches spans on a background thread by default. For scripts, notebooks, Lambda handlers, and one-off jobs, call tracer.flush() (or initialize with disable_batch=True) before the process exits, otherwise the last batch of spans may be dropped. See Span Export Modes.

Migration checklist

  • Replace honeyhive-logger with honeyhive>=1.0.0
  • Export HH_API_KEY in the environment (API keys are project-scoped; remove any HH_PROJECT or project= left over from logger code)
  • Initialize one HoneyHiveTracer at startup
  • Replace start() with create_session(), acreate_session(), or with_session()
  • Replace function-level log() calls with @trace
  • Replace block-level log() calls with enrich_span_context()
  • Replace event update() calls with tracer.enrich_span(event_id=...)
  • Replace session update() calls with tracer.enrich_session(...)
  • Call tracer.flush() (or set disable_batch=True) for scripts, notebooks, and serverless handlers
  • Add provider instrumentors where automatic tracing is useful
  • Confirm traces show nested spans and session outputs in HoneyHive

Custom Spans

Learn decorator and manual span patterns.

Tracer Initialization

Place tracer initialization correctly for your runtime.

Enriching Traces

Add metadata, metrics, feedback, and outputs.

OpenAI Integration

Add automatic model call tracing.