Conventions

Response envelope

Every response from the resource endpoints uses one JSON envelope:

{ "success": true, "code": 200, "message": "Events retrieved.", "data": { } }

• All successful responses are HTTP 200.
• A list is returned under a plural key (for example data.events) with data.cursor_pagination; a single record under a singular key (for example data.event).
• Delete and link/unlink operations return data: [].
• Each resource returns a fixed, documented set of fields. Only documented request fields are accepted; anything else is ignored. Passwords and other credentials are never returned or writable.

Identifiers and timestamps

• Most resources use integer ids. Events, attendees, registrations, users, user data, stakeholders, teams and event stakeholders use 26-character ULID strings.
• created_at, updated_at and deleted_at are ISO 8601 in UTC, for example 2026-07-17T11:02:14.000000Z.
• Single-record (GET …/{id}) responses embed some related records (documented per resource); list responses stay flat.

Pagination and incremental sync

Lists are cursor-paginated: per_page defaults to 25 (maximum 100). Follow data.cursor_pagination.next_page_url until it is null — it keeps your filters. There are no page numbers or totals, which keeps traversal stable while data changes.

Resources with an updated_at are ordered by updated_at, then id. Pass updated_since to fetch only records changed at or after an instant: checkpoint the largest updated_at you receive and send it next time. The feed is at-least-once — a record can appear again but will not be skipped. A few resources have no updated_at; they are ordered by id and ignore updated_since (each one says so).

Deletes

Each resource deletes in one of three ways (shown on every operation as x-eventogy-delete-mode):

• Soft (most resources): DELETE sets deleted_at. The record leaves default lists but is still returned by id, and appears as a tombstone in lists when you pass include_deleted=1 or any updated_since. PATCH …/{id} restores it. Updating, deleting or linking a soft-deleted record returns 404.
• Hard: DELETE removes the record permanently. There is no tombstone, so an updated_since sync cannot see the deletion, and there is no restore.
• Read-only: only GET is available; write methods return 405.