After the initial full roster sync, record the ID of the most recent event by calling the events endpoint and storing the returned event ID
On each subsequent sync cycle, GET /v3.0/events?starting_after=LAST_EVENT_ID to retrieve only events that occurred after the last processed event; events cover users, sections, and enrollments created, updated, or deleted
Process events strictly in chronological order as returned; out-of-order processing increases the risk of sync errors such as deleting a record before its update is applied
For each event, determine the object type and action (created, updated, deleted) then apply the corresponding create, update, or delete operation in your local data store; re-fetch the full object from the Clever API if you need the complete record, not just the event payload
Persist the ID of the last successfully processed event after each batch so that a failure mid-batch can resume from the correct position on retry
Known gotchas
The events window covers only 30 days of history; an application that goes offline for more than 30 days will have a gap in its event log and must perform a full re-sync to recover
Events are available only to Secure Sync customers; applications using the Clever Instant Login flow but not Secure Sync do not have access to the events endpoint
An event record contains minimal data (object ID, type, action) rather than the full object; fetching the full object for each event multiplies API calls significantly and may hit rate limits for large districts
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