Read and write Zoho People HR forms and employee records, attendance check-in/out, leave and time-tracker time logs, across every Zoho data centre.
Zoho People ships in the w6w first-party pack. It declares 19 actions, 2 health checks, and the host runs its code in a sandbox that never sees the credential.
io.w6w.zoho-peopleZoho People is an HR system, and this app covers its core automation surface: list the account’s forms, their fields and views; fetch, create and update records in any form (Employee, Leave, a custom form); look up an employee by email or employee id; read a day’s attendance entries and record a check-in/check-out; read leave types and balances and holidays, apply for leave and cancel a leave record; and list time-tracker jobs, projects, time logs and timesheets and add a time log.
Zoho hosts every People account in one of ten regional data centres, each with its own API host and (almost always) its own OAuth host, so this app routes each region through its own dedicated connection rather than one that could silently send an EU account’s requests through the US region.
Scoped to Zoho People specifically; Zoho’s other products (CRM, Recruit, Books, Desk, Mail) are separate apps in this pack. Attendance bulk import, timesheet create/approve/delete, timer start/stop, time-log modify/delete and the time-tracker’s client/project/job write APIs are deliberately left out.
Three routes to the same 19 actions. The Workflow tab is generated from Zoho People's own manifest and carries its real ids, so it is copy-pasteable; the Code and CLI examples are the same call for any action on any app, so every app-specific value in them is a blank you fill in.
attendance-check Record a check-in and/or check-out for one employee. Times are `dd/MM/yyyy HH:mm:ss`. Identify the employee by empId, emailId or mapId. For many entries use Zoho's Attendance Bulk Import (not included).
attendance-entries-get Get an employee's check-in/check-out entries and totals for a day. Identify the employee with one of erecno / mapId / emailId / empId; with none, the connected user's own entries are returned.
employee-get Look up one employee record (with tabular sections) by email address or Employee ID, via the `employee` form.
form-fields-get List the field components of a form (label name, type, mandatory flag) — the names to use in record-create and record-update.
form-list List the forms in the Zoho People account with their `formLinkName`, display name and permissions.
form-views-list List the views of a form — the `viewName` values List Records By View needs.
jobs-list List time-tracker jobs assigned to a user (the `jobId` values Add Time Log needs).
leave-apply Add a leave record through the `leave` form. Dates use `dd-MMM-yyyy` (07-Jan-2026). For half/quarter days or hour-based types pass `days`, per day: `{ "07-Jan-2026": { "LeaveCount": 0.5, "Session": 2 } }` (0.25 = quarter day; hour-based `LeaveCount` is `hh:mm`).
leave-cancel Cancel a leave record by its record id (from List Records on the `leave` form).
leave-types-get Get an employee's leave types with permitted, availed and balance counts and each type's Id (needed by Apply Leave).
projects-list List time-tracker projects, optionally for one user, client, status or manager.
record-create Add a record to any form. `fields` is keyed by the form's field LABEL names (see Get Form Fields); tabular-section values are JSON arrays.
record-list Fetch records of any form (employee, leave, a custom form) with their tabular-section rows, up to 200 per call. Page with `sIndex` (starts at 1).
record-update Modify field values of an existing record in any form. Get the `recordId` from List Records.
timelog-add Add a time log against a job. Give either `hours` or both `fromTime` and `toTime`. Zoho refuses weekends/holidays/leave, future or too-old dates, and >24h/day depending on the account's time-tracker settings.
timelogs-list Fetch time logs for a user and date range. The API allows at most one month between fromDate and toDate per call.
timesheets-list List timesheets for a user (or `all`), filtered by approval status and date range.
view-records-list Fetch the records of a form's view (e.g. `P_EmployeeView`) keyed by the view's display column names. The API is rate-limited to 30 calls/minute.
A workflow step names the app and the action, and the editor fills in the
connection when you pick one. This is the Step shape from the
workflow spec, carrying Zoho People's real ids.
{
"manifestVersion": "2",
"name": "zoho-people-example",
"steps": [
{
"id": "employee-get",
"uses": {
"app": "io.w6w.zoho-people",
"action": "employee-get",
"connection": "conn_YOUR_CONNECTION_ID"
},
"with": {
"identifier": "<identifier>"
}
}
]
}employee-get attendance-check attendance-entries-get form-fields-get form-list +14 more actions available
Every app-specific value here is a blank you have to fill in. An
app action is reached through the connection that authenticates it, so the
address is a connection id, not the app id — and connections belong to your account,
so a public page cannot know yours. Create one for Zoho People, then fill in
the three blanks: conn_YOUR_CONNECTION_ID, the action key, and the
parameters that action declares. The call itself is real — the shape is transcribed
from the studio's own snippet builder, which prints the same kind of blanks — but
nothing in it is specific to Zoho People. The Workflow tab is where this app's
real ids are.
npm install @w6w/sdkyarn add @w6w/sdkpnpm add @w6w/sdkdeno add npm:@w6w/sdkimport { W6wClient, isActionRun } from "@w6w/sdk";
// Reads W6W_BASE_URL and W6W_TOKEN from the environment when omitted.
const client = new W6wClient();
const envelope = await client.run({
urn: "conn_YOUR_CONNECTION_ID",
action: "employee-get",
payload: {
identifier: "<value>",
// identifierType: "<value>",
},
});
if (isActionRun(envelope)) console.log(envelope.value); npm install -g @w6w/cli w6w run conn_YOUR_CONNECTION_ID --action employee-get --payload '{"identifier":"<value>"}' Give an AI agent Zoho People — without giving it Zoho People's credentials. One MCP endpoint exposes every app, function and workflow the caller is entitled to, as tools it can discover and run. Access is granted per team while we onboard.
One tool call{
"name": "w6w_invoke",
"arguments": {
"ref": "app:io.w6w.zoho-people#employee-get",
"input": {
"identifier": "<identifier>"
}
}
}
Every tool names its target with a single ref. The
app: form above doesn't name a connection at all — the
host resolves which of the caller's Zoho People connections to sign
with, and refuses rather than guesses when the answer is ambiguous.
The token is attached host-side, at the moment of the call. It is never a tool argument, never in the model's context, and never in a transcript — so a prompt injection has nothing to exfiltrate.
Tools are derived per end user from what that person has actually connected and is entitled to — not one shared bot identity carrying the union of everyone's access.
Multi-step work runs on the workflow engine and returns a run handle the agent can poll — retries, branching and state survive the conversation that started them.
Zoho People's declared health checks are on the surface too, so an agent can tell "the vendor is down" from "your credential expired" before it burns a retry on either.
The MCP surface is part of the hosted platform. Zoho People itself is MIT, and the runtime that executes it is source-available (FSL).
Zoho People declares its own checks, so its health is a property of the app rather than something the host guesses at.
Reads the "Zoho People" component off Zoho's StatusIQ RSS feed (us.zohostatus.com/rss). Unauthenticated and unsigned.