Skip to main content

When to Use Custom Logging

Use the log_request method when:
  • You’re not using pl_client.run() for executing prompts
  • You need more flexibility (e.g., background processing, custom models)
  • You want to track requests made with your own LLM client code (OpenAI, Anthropic, etc.)
  • You want to log requests from any LLM provider
While custom logging requires more manual work than the run() method, it offers greater control over the logging process and supports any LLM provider.

API Reference

For complete documentation on the log_request API, see the Log Request API Reference.

Request Parameters

When logging a custom request, you can use the following parameters (see API Reference for details):
  • provider (required): The LLM provider name (e.g., “openai”, “anthropic”)
  • model (required): The specific model used (e.g., “gpt-4o”, “claude-3-7-sonnet-20250219”)
  • input (required): The input prompt in Prompt Blueprint format
  • output (required): The model response in Prompt Blueprint format
  • request_start_time: Timestamp when the request started
  • request_end_time: Timestamp when the response was received
  • prompt_name: Name of the prompt template if using one from PromptLayer
  • prompt_id: Unique identifier for the prompt template
  • prompt_version_number: Version number of the prompt template
  • prompt_input_variables: Variables used in the prompt template
  • input_tokens: Number of input tokens used
  • output_tokens: Number of output tokens generated
  • tags: Array of strings for categorizing requests
  • metadata: Custom JSON object for ability to search and filter requests later
  • api_type: Api type to be used when working with openai/azure-openai (e.g, “chat-completions”, “responses”)

Basic Usage

The input and output must be in prompt blueprint format:
Message content must be an array of content blocks, not a plain string.Use "content": [{"type": "text", "text": "your message"}] instead of "content": "your message". Using a plain string will result in a “Malformed Request” error in the dashboard.

Provider Conversion Helpers

OpenAI Format Converter

Anthropic Format Converter

OpenAI Example

Anthropic Example

Logging Extended Thinking and Reasoning

When logging requests that use extended thinking (Anthropic), thinking mode (Google), or reasoning (OpenAI), you need to:
  1. Include the thinking configuration in parameters - Use the provider-specific format
  2. Include thinking content blocks in the output - Add them to the message content array

Anthropic Extended Thinking

For Anthropic models with extended thinking enabled, pass the thinking parameter:

Google/Gemini Thinking Mode

For Google models with thinking mode, use the thinking_config parameter:

OpenAI Reasoning Models (o1, o3, etc.)

For OpenAI reasoning models, use the reasoning_effort parameter:
The parameter name varies by provider — make sure to use the correct format for your provider as shown above.

Working with Tools and Function Calls

For OpenAI/Anthropic function calling or tool use:
Important: When logging assistant messages with tool calls but no text content, you must include an empty content array (not null or omitted). This ensures proper display in the PromptLayer dashboard.

Error Tracking

Use status, error_type, and error_message when logging failed or degraded requests. This keeps warnings and failures searchable in PromptLayer and makes provider reliability easier to monitor.
  • SUCCESS means the request completed normally.
  • WARNING means the request succeeded but had issues, such as retries or partial responses.
  • ERROR means the provider call or prompt rendering failed.
Use a specific error_type such as PROVIDER_TIMEOUT, PROVIDER_RATE_LIMIT, PROVIDER_AUTH_ERROR, TEMPLATE_RENDER_ERROR, or UNKNOWN_ERROR when possible, and include a short error_message with the provider or application detail.

Complete JavaScript Example