How it works
Most workplace APIs are REST APIs. Each type of record, such as a booking or a check-in, has an address, and a system sends an authenticated request to list, create, update or cancel it. Access is controlled with API keys or OAuth tokens limited to what each integration needs.
Webhooks cover the other direction. Instead of polling for changes, the external system registers an address, and the workplace platform sends it an event as soon as something happens: a booking is created, a person checks in, a visitor arrives.
The common uses are presence and data. A badge system can call the check-in endpoint when someone swipes, so bookings reflect who is actually in. A data team can pull bookings and check-ins into a warehouse each night and combine them with HR, finance and lease data. Agent protocols such as MCP build on the same records for AI assistants.
How to measure it
- List the records the API exposes and whether each is read-only or read-write.
- Check authentication, rate limits and whether keys can be scoped, rotated and revoked.
- Confirm webhook delivery: retries, signatures and an event log.
- Compare an API export with the app's own report for the same period to test completeness.
Examples
- A badge system sends a check-in to the workplace platform each time an employee swipes into the building.
- A nightly job exports bookings and check-ins to a data warehouse for a finance dashboard on cost per occupied desk.
- A webhook tells a security system when a visitor checks in.
Common mistakes
- Building reports on bookings alone when check-in data is available; bookings overstate use.
- Sharing one broad API key across several integrations, which makes access hard to audit or revoke.
- Polling constantly when webhooks exist for the same events.
How Kadence helps
Kadence has a public REST API with API keys on all plans, covering buildings, users, bookings and check-ins, so badge or sign-in systems can check people in and data teams can pull bookings. Outbound webhooks send real-time events to other systems, such as security or badge tools, and an Audit Export API streams audit logs to a SIEM.
Frequently asked questions
What is a check-in API?
A check-in API lets another system confirm that a person has arrived for their booking, for example when they swipe a badge, sign in to a work computer or join the office network. It turns bookings into verified attendance without asking people to tap a button, which makes occupancy data more accurate.
What is the difference between an API and a webhook?
With an API, your system asks for data or sends a change when it chooses. With a webhook, the workplace platform tells your system the moment something happens. Most integrations use both: webhooks to react to events and the API to fetch details or make changes.
What can you build with a workplace API?
Common builds are automatic check-in from badge or network systems, bookings shown inside an intranet or kiosk, alerts when key safety roles are not on site, and nightly exports of bookings and check-ins to a data warehouse for finance and real estate reporting.
Is a workplace API secure?
It can be, if access is controlled well. Look for encrypted connections, keys or tokens that can be limited in scope and revoked, audit logs of API activity, and signed webhooks. Give each integration its own key so you can see and cut off access separately.
Related terms
- MCP (Model Context Protocol) An open standard that lets AI assistants use tools and data in other systems, such as booking a desk, without custom integrations.
- HRIS integration A connection that syncs joiners, leavers, teams and leave dates from the HR system into workplace software automatically.
- Badge data Access-control swipe records showing who entered a building or floor and when, often used to measure attendance.
Kadence editorial team · Last reviewed