Event logs

The Event Logs API is the integration delivery log: one entry per event sent to one integration destination, recording whether it arrived. Use it to debug event delivery — to answer “did this event reach Amplitude, and if not, why”.

This is not a raw log of user events. It records deliveries to integrations, not the events themselves. For the events themselves, see Events, which lists recorded events.

Key concepts

Entry — One delivery of one event to one destination. The same event delivered to three integrations produces three entries.
track_event_id — The recorded event that was delivered. It ties an entry back to GET /v4/events.
target_id — The target: the app in your project the event belongs to. It does not identify the integration.
Destination — The integration the event was delivered to is the pair integration_name (for example, Amplitude) and uid.
Outcome — is_success is a boolean; failed_code carries the failure code and is null on success. Note the asymmetry: the response field is is_success, while the query filter that selects on it is filter[success].
Read-only — The log can only be read. There is no endpoint that writes, retries or deletes an entry.
Time window — from and to bound the range, which is at most 24 hours wide. See below.

Available endpoints

Method	Endpoint	Description	Status
GET	`/event-logs`	List integration delivery log entries	New

The time window

from and to are optional Unix timestamps in seconds (non-negative integers). The window is at most 24 hours wide; a wider one is rejected with 400.

You send	The server reads
neither	the last 24 hours
`to` only	`from` = `to` − 24 hours
`from` only	`to` = now — so this works only when `from` is within the last 24 hours
both	exactly that range, if `to` − `from` is 24 hours or less

from greater than to is rejected with 400, and the error names the from field. There is no call that returns a longer period at once. To read further back, request consecutive 24-hour windows. For example, the last 7 days take seven requests, each window ending one second before the next one starts:

NOW=$(date +%s)
for i in 0 1 2 3 4 5 6; do
  TO=$((NOW - i * 86400))
  FROM=$((TO - 86400 + 1))
  curl --get 'https://api.qonversion.io/v4/event-logs' \
    --header 'Authorization: Bearer sk_YOUR_SECRET_KEY' \
    --data-urlencode "from=$FROM" \
    --data-urlencode "to=$TO" \
    --data-urlencode 'filter[success]=false'
done

If a window holds more entries than limit, page through it with offset before moving to the next window.

Filtering and paging

Parameter	Values	Description
`filter[track_event_id]`	comma-separated, max 50	Only deliveries of these events
`filter[target_id]`	comma-separated, max 50	Only deliveries of events from these targets (apps in the project)
`filter[success]`	`true`, `false`	Only successful or only failed deliveries
`sort_by`	`track_event_id`, `target_id`, `success`, `failed_code`, `updated_at`, `created_at`	Default `created_at`
`sort_order`	`asc`, `desc`	Default `desc`
`from`, `to`	Unix seconds	Time range; see The time window
`limit`	`1`–`100`	Default `20`
`offset`	`0`–`100000`	Default `0`

This endpoint pages with limit and offset, not with the starting_after cursor the collection endpoints use — the same as /events.

Authentication

All v4 endpoints require a Secret Key. See Authentication.

Start here

Resource guides

REST API v4

Analytics API

Legacy: API v3

Key concepts

Available endpoints

The time window

Filtering and paging

Authentication

​Key concepts

​Available endpoints

​The time window

​Filtering and paging

​Authentication

Key concepts

Available endpoints

The time window

Filtering and paging

Authentication