Check if a specific event has been successfully created for a user.

When to Use This Endpoint

• Verify event creation: Confirm that a previously submitted event (via POST /v1/events or POST /v1/events/batch) was successfully processed
• Deduplication checks: Before sending an event, check if it already exists to avoid 409 Conflict errors
• Integration testing: Verify your event tracking implementation is working correctly
• Debugging: Troubleshoot why events aren't appearing in analytics or triggering rewards
• Idempotency verification: Confirm that duplicate events were properly deduplicated

When NOT to Use This Endpoint

• Don't use for real-time tracking: This only checks if an event exists, not whether it triggered rewards (use GET /v1/conversions/status for conversion tracking)
• Don't use for analytics: For analytics and reporting, use leaderboard or payout endpoints
• Don't use as primary deduplication: Use dedup_id parameter in POST /v1/events for proper deduplication instead of checking status first
• Don't poll for event processing: Events are processed synchronously; if POST /v1/events returns 201, the event is created

How It Works

Returns {"created": true} if an event with the specified parameters exists in the system, {"created": false} otherwise.

Query Parameters:

• user_identifier: The user who performed the action
• user_identifier_type: Type of identifier (address, email, etc.)
• event_name: The name of the event to check

The endpoint searches for ANY event matching all three parameters, regardless of when it was created or what other metadata it has.

Important Constraints

• Required API Key Scope: Standard API key (no special scope required)
• Rate Limit: 100 requests/minute (standard rate)
• Case-sensitive: Event names are case-sensitive (trade ≠ Trade)
• No dedup_id check: This checks for event existence by name/user, NOT by dedup_id
• Identifier type matters: Same address with different types (e.g., address vs email) are treated as different users

Response Behavior

• {"created": true} - At least one event with this user_identifier + event_name combination exists
• {"created": false} - No event with this combination exists

Note: This does NOT tell you:

• How many times the event was created
• When the event was created
• What metadata the event contains
• Whether the event triggered any conversions

Common Errors

• 400 Bad Request:

  • Missing or invalid user_identifier
  • Missing or invalid event_name
  • Invalid user_identifier_type

• 401 Unauthorized:

  • Missing or invalid API key

• 403 Forbidden:

  • API key doesn't have access to this project

• 404 Not Found:

  • Project not found (API key references non-existent project)

• 429 Too Many Requests: Rate limit exceeded (100 requests/minute)

Related Endpoints

• POST /v1/events - Create a single event (the event you're checking status for)
• POST /v1/events/batch - Create multiple events in batch
• GET /v1/conversions/status - Check if an event triggered a conversion/reward

Best Practices

1. Use dedup_id for deduplication: Don't rely on this endpoint for preventing duplicates; use unique dedup_id in POST /v1/events instead
2. Cache results: Event existence doesn't change (events are immutable), so you can cache created: true responses indefinitely
3. Don't poll: Events are created synchronously; if POST /v1/events succeeds (201), the event exists
4. Use for verification only: This is primarily useful for debugging and testing, not production event flows

Example Use Case

Scenario: User completes a trade, your backend sends POST /v1/events, but you want to verify it was received:

1. POST /v1/events with dedup_id: "trade_12345" → Returns 201 Created
2. GET /v1/events/status?user_identifier=0x123&user_identifier_type=address&event_name=trade
3. Response: {"created": true} ✓ Confirmed