Events API: documented `order` parameter is silently ignored (always oldest-first) despite SDK sending it since #1524

[TBIQ007]

Summary

The REST API reference for List Events documents an order query parameter ("Supported values are asc, desc, and normal … Defaults to desc"), but the live GET /events endpoint appears to silently ignore it: order=desc, order=asc, order=normal, and omitting the parameter all return byte-identical, oldest-first pages. The documented default (desc) also doesn't match observed behavior (ascending).

This SDK deliberately exposes the parameter: #1524 ("fix(events): add missing order parameter to listEvents", merged 2026-03-18) added order?: 'asc' | 'desc' to ListEventOptions and to the serialized request — so current SDK versions send order on the wire, and the endpoint ignores it. Anyone who upgraded to pick up #1524 is getting silently wrong ordering. Filing here since I couldn't find a public tracker for the API itself.

Reproduction (any sandbox sk_test_ key)

for ord in desc asc normal; do
  echo "=== order=$ord ==="
  curl -sS "https://api.workos.com/events?order=$ord&limit=3&events=user.created" \
    -H "Authorization: Bearer $WORKOS_API_KEY" | jq -r '.data[] | "\(.id) \(.created_at)"'
done
echo "=== no order param ==="
curl -sS "https://api.workos.com/events?limit=3&events=user.created" \
  -H "Authorization: Bearer $WORKOS_API_KEY" | jq -r '.data[] | "\(.id) \(.created_at)"'

Observed (2026-06-11, sandbox environment): all four variants return the same three oldest events in ascending created_at order, with the same list_metadata.after cursor.

Ruling out "nothing newer exists"

The environment provably contains much newer events — constraining with range_start returns them — and order=desc within that window still returns oldest-first, identical to the unordered call:

curl -sS -G "https://api.workos.com/events" \
  --data-urlencode "limit=3" \
  --data-urlencode "events=user.created" \
  --data-urlencode "range_start=2026-06-10T00:00:00.000Z" \
  --data-urlencode "order=desc" \
  -H "Authorization: Bearer $WORKOS_API_KEY" | jq -r '.data[] | "\(.id) \(.created_at)"'

Returns the oldest events after range_start, ascending — not the newest.

Ruling out a malformed request

The endpoint validates its other parameters strictly on the same calls — omitting events returns invalid_events_request, and a malformed range_start returns invalid_date_range_exception — so the query string is clearly being parsed; order specifically is ignored without an error.

Expected

One of:

1. order=desc returns newest-first (matching the API reference), or
2. the API reference for GET /events drops the order parameter and documents the endpoint as oldest-first cursor-paged only (matching actual behavior and this SDK's option surface), or
3. unsupported values/params produce an error instead of being silently ignored.

Environment

• Verified against a sandbox environment (sk_test_) on 2026-06-11; unable to verify whether production environments behave differently.
• Reproduced with raw curl (no SDK in the path), so this is independent of any client library.

Impact

Anyone trying to fetch the newest event (e.g. order=desc&limit=1 to find the head of the stream for cursor seeding) silently gets the oldest event instead — no error, just wrong data. The only workaround is paging ascending to the end of the stream.