canonical: https://jentic.com/apis/envoy.com/envoy

# Envoy Visitor Management API

Envoy is a workplace platform that handles visitor sign-in, deliveries, room and desk reservations, and employee scheduling. The API provides programmatic access to entries, flows, locations, companies, invitations, employees, work schedules, and reservations so corporate IT and people-ops teams can wire Envoy into HR systems, identity providers, and analytics tools. The 19-endpoint surface is focused on the workplace operations data model rather than building a full visitor experience from scratch.

## For AI agents

Read visitor entries, manage employee invitations and work schedules, and sync locations and reservations from the Envoy workplace platform.

## Scope

Does not handle physical access control, badge printing, or full HRIS data - use for visitor entries, invitations, employees, work schedules, and reservation reads only.

## Capabilities

- List visitor entries and retrieve a single entry by ID for reporting and audit trails
- Read and look up flows that determine the sign-in experience for different visitor types
- Read locations and companies via the rest/v1 endpoints to align Envoy data with internal directories
- Create, update, and delete invitations so expected visitors are pre-registered
- Read employee records and synchronise employee status with HR or identity providers
- Read work schedules to drive office attendance reporting and capacity planning
- Read reservation records for desks and rooms tied to Envoy's workplace product

## Use cases

### Visitor Sign-In Audit and Reporting

Pull entries with GET `/v1/entries` on a schedule into a data warehouse or compliance report so security and facilities teams have a complete record of who visited each location. Combine with `/v1/flows` to label each entry by visit type. Useful for SOC 2 and similar audits that require visitor logs.

Example prompt: Call GET `/v1/entries` with the desired date range and load the results into the warehouse table for compliance reporting.

### Pre-Registered Visitor Invitations

When an external system schedules a meeting, create an Envoy invitation via POST `/v1/invitations` so the visitor's name and arrival time are pre-loaded at the front desk. Update or cancel the invitation if the meeting changes via PUT or DELETE on `/v1/invitations/{id}.` This integration removes manual front-desk entry and shortens visitor wait time.

Example prompt: Submit POST `/v1/invitations` with the visitor's name, email, and arrival time, then store the returned invitation ID against the meeting record.

### Employee and Work Schedule Sync

Read employee records via GET `/v1/employees` and pull schedules via GET `/v1/work-schedules` to feed office attendance dashboards and capacity-planning tools. Pair with HR data to detect mismatches between the Envoy directory and the source-of-truth HRIS so people-ops can keep records aligned.

Example prompt: Pull GET `/v1/employees` and reconcile email addresses against the HRIS to surface any employees missing from Envoy.

### AI Agent Workplace Assistant Through Jentic

An AI workplace assistant uses Jentic to discover Envoy operations by intent and answers questions like 'who is visiting today?' or 'register Jane as a guest at 2pm' by chaining `/v1/entries` reads with `/v1/invitations` writes. The Envoy bearer token stays in your Jentic One instance and never enters the agent's prompt context.

Example prompt: Search Jentic for 'register a visitor in Envoy', load POST `/v1/invitations`, and execute it with the visitor's details for tomorrow's meeting.

## Key endpoints

| Method | Path | Description |
| --- | --- | --- |
| GET | `/v1/entries` | List visitor entries |
| GET | `/v1/entries/{id}` | Get a single entry by ID |
| GET | `/v1/flows` | List sign-in flows |
| POST | `/v1/invitations` | Create a pre-registered visitor invitation |
| PUT | `/v1/invitations/{id}` | Update an invitation |
| DELETE | `/v1/invitations/{id}` | Delete an invitation |
| GET | `/v1/employees` | List employees |
| GET | `/v1/work-schedules` | List work schedules |

## Key resources

- **Entries** — Read visitor entry records, including individual entry retrieval by ID.
- **Flows** — Read flow definitions that govern different visitor sign-in experiences.
- **Locations** — Read the list of configured Envoy locations and individual location details.
- **Companies** — Read company records via the rest/v1/companies endpoint.
- **Invitations** — Create, read, update, and delete pre-registered visitor invitations.
- **Employees** — Read employee records synchronised into Envoy.
- **Work Schedules** — Read work schedules used for office attendance and capacity planning.
- **Reservations** — Read desk and room reservation records tied to Envoy's workplace product.

## Why Jentic

- **Setup:** Wiring Envoy by hand means handling its bearer-token auth, choosing between the API and app hosts, and building your own retries for the visitor and invitation calls. Through Jentic you install once, import the Envoy Visitor Management API from the API Directory, store the bearer token once, and your agent calls it.
- **Permission scoping:** Scope the agent to the operations it needs, such as creating an invitation at POST `/v1/invitations` or reading entries at GET `/v1/entries.` You pick that allowed set, so a destructive operation like DELETE `/v1/invitations/{id}` is not included unless you add it.
- **Credential handling:** Your Envoy bearer token is stored once, encrypted, by your own Jentic One instance and injected at execution time. It never enters the agent's prompt, logs, or context.
- **Discovery method:** Agents search Jentic by intent such as 'pre-register a visitor in Envoy' or 'list today's entries', and Jentic returns the matching Envoy operation with its input schema so the agent calls the right endpoint without browsing the reference docs.

## Related APIs

- **Robin** — Workplace platform focused on desk and room booking
- **Calendly** — Schedule the meeting that drives the Envoy invitation
- **Slack** — Notify host employees when visitors sign in

## FAQ

### What authentication does the Envoy API use?

The Envoy API uses HTTP bearer token authentication. Each request must include an Authorization header with a bearer token issued from the Envoy dashboard. Through Jentic, the token is stored encrypted in your Jentic One instance and injected at execution time so it never enters the agent context.

### Can I pre-register visitors with the Envoy API?

Yes. POST `/v1/invitations` creates an invitation that pre-loads the visitor's information at the front desk. PUT `/v1/invitations/{id}` updates the invitation and DELETE `/v1/invitations/{id}` cancels it. This is the supported way to integrate scheduling systems with Envoy.

### How do I list visitor entries?

Call GET `/v1/entries` with the desired date and location filters. For a single entry, GET `/v1/entries/{id}` returns the full record. The endpoints back compliance reporting and visitor analytics flows.

### What are the rate limits for the Envoy API?

The OpenAPI spec does not publish numeric rate limits. Envoy applies plan-based throttling at the account level - contact Envoy support if your integration needs sustained high-throughput access for entry sync or large bulk operations.

### How do I create a visitor invitation through Jentic?

Search Jentic for 'create a visitor invitation in Envoy', load POST `/v1/invitations`, and execute it with the visitor's name, email, and arrival time. Get started with Jentic One, the self-hosted execution layer.

### Does the Envoy API expose work schedules and reservations?

Yes. The Work Schedules and Reservations tags expose read endpoints for employee schedules and desk/room reservations, supporting office attendance reporting and capacity planning workflows.

### Can I limit what my agent is allowed to do with the Envoy Visitor Management API?

Yes. Because Jentic One is self-hosted by you, your own rules decide exactly which Envoy operations the agent may call and which stored credentials it may use. You can allow just the operations you need, such as reading entries at GET `/v1/entries` or creating a pre-registered visitor at POST `/v1/invitations`, while leaving destructive calls like DELETE `/v1/invitations/{id}` out of the allowed set. The agent can only invoke the operations you explicitly grant, and the Envoy bearer token stays in your instance and is injected at execution time rather than exposed to the agent.
