Skip to main content
Send conversion or marketing events for attribution and optimization. Supports batch submissions, test events, and partial failure reporting. Response Time: ~1s (events are queued for processing) Request Schema: /schemas/v3/media-buy/log-event-request.json Response Schema: /schemas/v3/media-buy/log-event-response.json

Quick Start

Log a purchase event:

Request Parameters

Event Object

User Match Object

At least one of uids, hashed_email, hashed_phone, click_id, or client_ip + client_user_agent is required: Hashing: Hashed identifiers must be SHA-256 hex strings (64 characters, lowercase). Normalize before hashing: emails to lowercase with whitespace trimmed, phone numbers to E.164 format (e.g. +12065551234).

Custom Data Object

Response

Success Response:
  • events_received - Number of events received
  • events_processed - Number of events successfully queued
  • partial_failures - Events that failed validation (with event_id, code, message)
  • warnings - Non-fatal issues (low match quality, missing fields)
  • match_quality - Overall match quality score (0.0 to 1.0)
Error Response:
  • errors - Array of operation-level errors (invalid event source, auth failure)
Note: Responses use discriminated unions - you get either success fields OR errors, never both. Partial failures are reported per-event within the success response.

Common Scenarios

Creator Engagement Events

Log creator or content engagement events against the configured owned-property source. Use surface to identify the property and put watch thresholds in custom_data.progress_percent or custom_data.progress_seconds.
test=false
For free durable opt-ins, use event_type: "follow". Reserve event_type: "subscribe" for paid subscriptions or paid memberships.

Batch Events

Send multiple events in a single request:

Test Events

Validate event integration without affecting production data:
Test events appear in the seller’s test events UI but do not affect production attribution or reporting.

In-Store Conversions

Report offline conversions using CRM data:

Event Deduplication

Events are deduplicated by the combination of event_id + event_type + event_source_id. Sending the same event multiple times is safe - duplicates are silently ignored. Choose event_id values that are stable across retries:
  • Transaction IDs: "order_98765"
  • Composite keys: "purchase_user123_20260115"
  • UUIDs: "550e8400-e29b-41d4-a716-446655440000"

Error Handling

Best Practices

  1. Configure sources first - Always run sync_event_sources before sending events. Events sent to unconfigured sources are rejected.
  2. Include user_match - Events without user identifiers cannot be attributed. Provide the strongest identifiers available: hashed email/phone > UIDs > click IDs > IP/UA. Send multiple identifier types when available to maximize match rates.
  3. Use test events first - Set test_event_code during integration to validate events appear correctly without affecting production data.
  4. Batch when possible - Send up to 10,000 events per request to reduce API calls. Events within a batch are processed independently.
  5. Include value and currency - For purchase events, always include custom_data.value and custom_data.currency to enable ROAS reporting and optimization.
  6. Stable event IDs - Use deterministic event IDs (order numbers, transaction IDs) rather than random UUIDs. This ensures safe retries without duplicate counting.
  7. Send events promptly - Log events as close to real-time as possible. Events outside the seller’s attribution window may not be matched.

Next Steps