Skip to main content
Quick Summary: The v1 API does not deliver webhooks. Detect changes by polling the activity feeds on a schedule, filtered by date, and send an Idempotency-Key on any write your poller triggers.

​
No webhooks

There is no webhook or event-subscription mechanism in v1 — SkillsDB never calls your systems. If your integration needs to react to changes, poll for them.

​
Polling the activity feeds

Three activity feeds are available, all newest-first and paginated, all sharing one activity event envelope: from and to take ISO 8601 UTC timestamps. Poll a feed by remembering when you last polled and asking only for what is new:
Process the entries, store the poll time, and use it as the next from. Overlap the windows slightly and deduplicate on the entry id rather than trusting an exact boundary. The skill feed is a version log, not a change feed: it emits only baseline, version_created and renew_training. The identity provider feed is company-wide rather than per object, and is the one to poll for changes SkillsDB did not originate — provisioning, group membership and permission changes from your identity provider. Its performer is always the identity provider, so it takes relatedPersonId instead of performedBy.

​
Keep the poller polite

Polls are GETs, counted against the reads bucket — 1,000 per hour per key. Watch RateLimit-Remaining and size your interval so a full sweep fits comfortably. If a poll result triggers a write back into SkillsDB, send an Idempotency-Key from day one — a poller that crashes mid-run and restarts will otherwise perform its writes twice.