Skip to main content

Installation

Quick Start

What Gets Traced

  • Chat completions — input messages (user text only), output text, model, token usage (prompt/completion)
  • Finish reason — azure_openai.finish_reason (stop, length, content_filter, tool_calls)
  • Extended tokens — ai.usage.cached_tokens (prompt cache hits) and ai.usage.thoughts_tokens (reasoning tokens for o1/o3 models)
  • Errors — captured with error status, re-thrown to caller

Configuration

Projects

Route events to a specific project by passing its slug as projectId (project_id in Python):
This sets the X-Raindrop-Project-Id header on every event. Omit it (or pass "default") to use your org’s default Production project, which is the existing behavior. Single-project orgs need nothing new.

Multiple projects in one process

Available in raindrop-ai>=0.0.56. When one service wraps several Azure OpenAI clients that should report to different projects, create one RaindropAzureOpenAI wrapper per project. Each wrapper owns its own raindrop.Raindrop client, so the two route independently — there is no shared module-level state:
Each wrapper owns its configuration and delivery pipeline, so clients handled by different wrappers route independently. To share a single client across wrappers (or with the module-level API), construct a raindrop.Raindrop yourself and pass it via client=:

Tool catalog capture (ai.prompt.tools)

TypeScript. Every chat.completions.create span records the request’s tools (or legacy functions) as ai.prompt.tools. Pass tools on createRaindropAzureOpenAI(...) to record a different list instead (it replaces the inferred one; tools: [] records an empty catalog). Python. raindrop-azure-openai ≥ 0.0.12 reads the list off the request itself: every model span under a wrapped chat.completions.create() records the call’s tools= (or legacy functions=), sync and async, and stream=True is covered because the OpenLLMetry openai instrumentation starts the span inside create() while the list is bound. Capture is exact; a request with neither records []. The instrumentation writes the same list to gen_ai.tool.definitions (OpenLLMetry ≥ 0.62 no longer emits llm.request.functions.*), which raindrop-ai ≥ 0.0.72 also rebuilds from; the wrapper does not depend on that, and its bound list takes precedence when both are present. Pass tools= on RaindropAzureOpenAI(...) / create_raindrop_azure_openai(...) as the default for every call, or wrap(client, tools=[...]) for one client; the per-wrap value replaces the default, either replaces the request’s list, and tools=[] records an empty catalog. Follows TRACELOOP_TRACE_CONTENT; needs raindrop-ai ≥ 0.0.70 and disable_auto_instrument=False (with the default True there is no model span at all). See Tool catalog capture for the attribute format, the absent / [] semantics and the override shapes accepted.

Flushing and Shutdown

User Identification

Tracking Signals

Application Git metadata (Python)

RaindropAzureOpenAI(...) and create_raindrop_azure_openai(...) accept the keyword-only app_git option. It defaults to True: explicit Raindrop Git environment or deployment context is applied immediately, and the base SDK may perform one bounded background local-Git lookup from the process working directory. Event capture, flush, and shutdown never wait for that lookup. Pass False to disable enrichment, or pass an AppGitOptions mapping with commit_sha, commit_dirty, branch, source_directory, detect_branch, and/or auto_detect. Automatic branch discovery remains opt-in through detect_branch=True (or RAINDROP_GIT_DETECT_BRANCH=true). For an ordinary in-process application, the process working directory is treated as the application-under-test checkout. A remote, coding, workflow, or observer process must not rely on its own checkout: pass app_git=False, provide explicit revision values, or set source_directory to the actual application checkout. Canonical per-operation properties remain authoritative. When supplying client=, configure app_git while constructing that Raindrop client; the supplied client is authoritative and the wrapper’s app_git argument does not reconfigure it. Release order is deliberate: first publish the base SDK feature, then publish the wrapper feature release with its minimum dependency coordinated to that base release. The existing raindrop-ai lower bound remains compatible, but application Git metadata is unavailable on an older core and must not be claimed complete until the base is upgraded. Until coordination assigns a released version, the wrapper checks for an explicit base app_git parameter and omits the option when unsupported. Explicit non-default configuration is debug-logged and omitted. Unsupported app_git is determined by signature inspection before construction, not by retrying initialization after a TypeError; Git configuration adds no initialization attempts and does not change any existing framework-specific initialization fallback.

Factory Function (Backwards-Compatible)

Python
Already using the Vercel AI SDK with Azure? The Vercel AI SDK integration automatically traces Azure OpenAI calls when you use the AI SDK’s Azure provider. This integration is for users calling the Azure OpenAI SDK directly.