The short version
- “Yes, we have an API” on a tender response can mean a documented interface, a partner plugin or a roadmap item. Ask which, in writing
- The answers that matter for a desk booking API are dull ones: how it authenticates, what it can read and change, how it limits and pages requests, and how changes are announced
- Ask which plan includes the API, single sign-on and SCIM provisioning. They are often on different tiers
- Ask for a test environment and one read-only request before contract signature. A vendor that can do that in a week has a real API
Integration requirements get a line in the tender and a tick in the response. The problem surfaces three months after go-live, when IT tries to connect the booking tool to the HR system and finds the tick meant something narrower than everyone assumed.
These are the questions that separate a usable desk booking API from a checkbox. HybridHero is our product, so we have included how we answer them and where our own limits are.
Three things a vendor can mean by API
| What they say | What it may be | How to tell |
|---|
| “We have an open API” | A documented, versioned interface you can call yourself. See open API | Ask for the API definition and the change log |
| “We integrate with that” | A connector built by the vendor or a third party, often through an automation tool | Ask who maintains it and what happens when it breaks |
| “It is supported” | Professional services will build it for a fee, or it is planned | Ask for a customer using it in production today |
None of the three is wrong. A maintained connector can be the better choice for a calendar or chat tool. The risk is paying for one and expecting another.
The twelve questions
| Question | Why it matters |
|---|
| 1. Which plan includes API access, SSO and SCIM, and is any of it a paid add-on? | These three are commonly split across tiers. Price the tier you will need, not the entry one |
| 2. Is there a test environment with safe data? | Without one, your first integration test runs against real bookings |
| 3. How do we authenticate, and how are credentials issued, rotated and revoked? | A shared key emailed in plain text is a finding in your next audit |
| 4. Which resources can we read and which can we change? | Reporting needs read access to bookings and spaces. HR sync needs write access to users. Many APIs offer only the first |
| 5. Can access be limited by location or tenant? | A regional integration should not see global data. See role-based access control |
| 6. Are check-ins and cancellations exposed, or only bookings? | Utilisation reporting is wrong without check-in status |
| 7. What are the rate limits, and how does pagination work on a full history pull? | A two-year backfill is the request most likely to be throttled |
| 8. Are event notifications available, and for which events? | If not, you poll. That is workable, but design for it from the start |
| 9. How are errors reported, and which are safe to retry? | Retrying a create request can double-book a desk |
| 10. How are versions numbered, and how much notice comes before a breaking change? | You will not be watching the vendor’s release notes. Someone has to tell you |
| 11. Where is the data held, and can every API call be traced in an audit trail? | Security review will ask both. See data residency |
| 12. How do we export everything if we leave? | Exit terms are easiest to agree before you sign |
What a good answer looks like
Good answers are specific and slightly inconvenient. “OAuth client credentials, scoped per location, keys rotate every ninety days” is a good answer. “Fully secure enterprise-grade API” is not an answer.
The strongest signal costs the vendor a week. Ask for a test environment and make one read-only request for a list of spaces before contract signature. If the vendor can arrange that, the API exists and someone supports it. If the conversation moves to a statement of work, you have learned what “supported” meant.
How HybridHero answers
We do not publish an open endpoint catalogue. Access is approved per integration, and the HybridHero developer portal sets out what gets confirmed before you connect: the tenant and identity the integration acts for, read and write scope, location restrictions, the authentication flow, credential delivery and rotation, and the approved environment and region.
| Question | HybridHero |
|---|
| Plan | Custom API and third-party integrations are part of the Enterprise plan. SSO and Active Directory integration sit on Professional and above. Confirm the plan for SCIM on your call. Pricing is by quote |
| Identity | SAML 2.0 and OIDC single sign-on with Microsoft Entra ID, Okta and Google. SCIM 2.0 provisioning with Okta, and user provisioning and deprovisioning with Microsoft Entra ID |
| First request | Read-only, in an approved test environment, checked against the documented schema |
| Event notifications | Confirmed per workflow. Ask for the event catalogue before building a consumer. Do not assume it |
| Audit and residency | Platform actions are logged and audit logs can be exported. Data residency options in the UK, EU, US and APAC. ISO 27001 certified |
If you need a public sandbox you can sign up for without talking to anyone, a vendor with a self-serve developer programme is a better fit. If you want the scope agreed with a named contact before anything touches production data, that is how ours works.
Frequently asked questions
What is a desk booking API?
A desk booking API is a programmatic interface to a desk booking platform. It lets other systems read or change people, spaces, bookings and check-ins without using the app, so HR systems, reporting tools and building systems can stay in sync.
What do companies use a desk booking API for?
The four common uses are syncing people from an HR or identity system, pulling bookings into Power BI or a data warehouse, linking check-ins to door access or sensors, and showing availability in an intranet or a chat tool.
Is a desk booking API usually included in the price?
Often not. API access, SSO and SCIM are frequently held for higher plans or sold as add-ons, and the three are not always on the same tier. Ask for the plan that includes all the integration features you need and compare on that.
Should a desk booking API support webhooks?
It helps for near real-time workflows such as releasing a desk when someone badges out. It is not essential for reporting or nightly HR sync, where scheduled polling is simpler and easier to recover when something fails.
How do I test a desk booking API before buying?
Ask for a test environment, credentials for one technical contact and the API definition. Make a read-only request for a list of spaces, then check the response against the documented schema. A week is a reasonable turnaround.
Who should be involved in a desk booking API evaluation?
The IT or integration lead who will build it, security for the credential and audit questions, and the workplace lead who knows which data the business needs. Procurement should see the plan and exit answers.
Where this fits
If single sign-on is the first integration on your list, the Okta and Microsoft Entra ID setup guide covers it, and the comparison of desk booking tools with SSO and SCIM shows which vendors include what. When you have a use case in mind, the developer portal is the place to request access.