A read API and five events.

What the API exposes

A scoped REST API over the structural half of the People Graph. Tokens are scoped narrowly and ideally issued one per integration, so a compromised token for an intranet directory cannot read anything else.

• People — identity, role, team, manager, location, employment type
• Teams — members, purpose, owned responsibilities
• Roles — purpose, responsibilities, authority, reporting line
• Responsibilities — owner, backup, cadence, escalation
• Skills and knowledge areas — holders and documentation links
• Availability — status by person and by date

What it never exposes

Compensation, employment documents and private manager notes are not reachable through the API regardless of token scope. There is no scope that returns them, which means an integration cannot leak them and a compromised token cannot reach them. If you need compensation data in another system, it goes through the payroll export, which is a separate and deliberately narrower path.

Events

Five webhooks, covering the moments worth reacting to. Deliveries are signed; verify the signature before acting, and treat delivery as at-least-once rather than exactly-once.

• person.joined — a new employment or engagement record starts
• person.left — a record moves to leaver state
• person.role_changed — role, team or manager changed
• responsibility.transferred — an owner or backup changed
• access.changed — a grant was added or removed

Writes are deliberately narrow

Two write paths exist: importing people, and recording an access grant that happened elsewhere. Nothing in the API changes an employment record, approves anything, or alters permissions. An automated integration doing any of those unattended is a bad idea in this domain, and making it impossible is more reliable than documenting that you should not.

Rate limits and pagination

Standard cursor pagination, and limits set per token rather than per organization so one noisy integration cannot starve another. The limits are published in the API reference rather than discovered by hitting them.

Testing

Every organization can create a sandbox with generated people, teams and responsibilities. Point your integration at that before production — particularly for anything consuming the leaver event, which is the one where a bug is most expensive.