Skip to content

Retrieving events

These endpoints are the general way to read events from reporting. They sit next to pipeline analytics on the same API host, but not under /pipeline, and they do not run a pipeline definition.

Base URL: https://api.giosg.com/api/objectives/v1/orgs/<organization_id>

Authentication

For server-to-server calls, authenticate with a user API token: Authorization: Token <api token>. OAuth2 access tokens use Authorization: Bearer <access token> instead. How to obtain and use each: Get API token. The URL organization_id must match the authenticated organization.

Three endpoints, three jobs:

Job Endpoint Typical use
Event type catalog POST /event-types Explore which generic-event type masks have been emitted
Generic event rows POST /events Widget, goal, case-management, shopping-cart, and other custom events
Chat message rows POST /message-events Individual chat messages by message_type

Two-day window

/events and /message-events accept at most 2 days per request (250 rows per page). Walk adjacent windows and paginate each one for a longer range. If cursor is sent, every other body field is ignored. The event type catalog has no such cap. Windows use collector_created_at; that field and timestamp are functionally the same (they may differ by milliseconds). Both exist for legacy reasons — a later API will use timestamp only.


Which guide to use

Row columns: generic events, message events.

To send generic events into reporting, see Creating new generic events. To aggregate them into funnel-style counts, see the Pipeline API. Generic-event filters can reuse pipeline value sets ($name).

Full request/response tables: Event listing reference.