Skip to main content
GET
List contradictions
Subject-scoped: every row is filtered WHERE user_id = <effective subject> (the API-key owner by default, or a provisioned subject via the X-Exo-Subject header). Ordered by detectedAt descending with id as a stable tiebreaker; page with nextCursor until hasMore is false. Every tension surfaces as open: the M1 store tracks no resolution, so status=resolved returns an empty page (documented honest subset). No totals (cursor pagination).

Authorization

This route requires the read scope. A missing or invalid credential returns 401 authentication_error. A valid credential without the scope returns 403 permission_denied, and the problem body names the exact scope required.

Headers

These are request conventions the contract does not declare as parameters, so they do not appear in the schema tables below.

Success responses

Errors

Every error is an RFC 9457 application/problem+json body carrying a stable code, a requestId, and a suggestedAction where Exo has one. See Errors.

Notes

  • Every tension comes back open. The v1 store tracks no resolution state, so status=resolved returns an empty page. That is a documented subset, not a bug.
  • Resolve one by superseding a side, with POST /v1/graph/nodes/{node_id}/supersede.

Authorizations

X-Exo-API-Key
string
header
required

An Exo API key (exo_...) sent as the X-Exo-API-Key header.

Query Parameters

status
enum<string> | null

Lifecycle filter. Only 'open' is representable today (the M1 store has no resolution lifecycle): 'open' or omitted returns all tensions; 'resolved' returns an empty page.

Available options:
open,
resolved
cursor
string | null

Opaque cursor from a previous nextCursor.

pageSize
integer | null

Page size, coerced into [1, 100] (default 25).

Response

Successful Response

data
Contradiction · object[]
required
hasMore
boolean
default:false
nextCursor
string | null