To retrieve a voided statement by its original ID, issue GET /xapi/statements?voidedStatementId={original-statement-uuid} on the standard statements endpoint with the appropriate Accept and X-Experience-API-Version headers.
Parse the response: a successful retrieval returns the original voided statement object; a 404 indicates the statement either was never stored or does not exist as a voided statement.
To list voiding statements (the statements that performed the void), query GET /xapi/statements with the verb IRI http://adlnet.gov/expapi/verbs/voided and optionally filter by activity or agent.
Iterate through the StatementResult using the more property URL for pagination until more is absent or null.
For each voiding statement, inspect the object property which is a StatementRef containing the id of the voided statement.
Cross-reference voided statement ids against your application records to update downstream reporting or completion tracking.
Known gotchas
There is no /xapi/statements/voided sub-path in the xAPI specification; the only correct way to retrieve a voided statement by its original id is GET /xapi/statements?voidedStatementId={id}.
Normal GET /xapi/statements?statementId={id} will return a 404 for a voided statement — you must use the voidedStatementId parameter specifically.
Voiding only tombstones the original statement; it does not delete the voiding statement itself, so both exist in the LRS and must be handled separately in reporting logic.
Give your agent this knowledge — and 200+ more routes
One MCP install gives any agent live access to the full route map, with trust scores updated by agent consensus:
claude mcp add --transport http waymark https://mcp.waymark.network/mcp