Timeero logo

Timeero

Time Tracking

GPS time tracking for field crews: Ruby can total labor hours, see who is clocked in, and read schedules and mileage.

39 tools
API KEY
Reads by default, writes opt-in

Ask Ruby

“Who's clocked in right now and which job are they on?”
“Total hours by employee for last week's pay period.”
“How many labor hours and miles went into the Maple St job?”
“Who's scheduled tomorrow, and is anyone off?”
What Ruby can do

17 read tools

Ruby reads from Timeero and grounds her answers in your data. Every connection starts read-only: she surfaces, summarizes, and drafts, and your team takes the action.

List users

List employees List the company's employees (crew members, supervisors, admins) with their role, pay rate, active status, and whether location and mileage tracking is enabled. Deleted users are not returned.

Get user

Get one employee Get a single employee's full record by user id: name, contact details, role, pay rate, tracking settings, and custom fields. (GET /users/{id})

List groups

List groups List the company's groups (crews, departments, or locations that employees are organized into). Group ids feed the group_id filter on users and timesheets.

Get group

Get one group Get a single group's information (name and members) by group id. (GET /groups/{id})

List jobs

List jobs List the company's jobs. In Timeero a job is whatever crews clock into: a customer, a loss address, a project, or a vehicle. Includes hourly rate, geofence settings, and active status. Job ids feed the job_id filter on timesheets and schedules.

Get job

Get one job Get a single job by id, including its custom geofence coordinates, hourly rate, mileage-tracking setting, and contact details. (GET /jobs/{id})

List tasks

List tasks List the tasks employees can clock into within a job (e.g. demo, water extraction, drying, packout).

Get task

Get one task Get a single task's information by task id. (GET /tasks/{id})

List timesheets

List timesheets (hours worked, by date range, employee, or job) The core labor-hours endpoint. Each entry carries the employee, job and task, clock-in/clock-out times and timezones, clock-in/out addresses and GPS coordinates, total hours, mileage driven, break count, flagged status, and approval state. Use it for payroll periods, job costing (labor hours and mileage per job), and per-employee productivity.

Get timesheet

Get one timesheet Get a single timesheet entry by id, with its full clock-in/out detail, mileage, breaks, and custom fields. (GET /timesheets/{id})

List schedules

List schedules (planned shifts) for a date range List planned shifts: who is scheduled for which job, when, and whether the shift is still a draft or published to the crew. Use it for dispatch questions about tomorrow or next week. The date_range parameter is REQUIRED.

Get schedule

Get one schedule Get a single scheduled shift by id, including its assigned employee, job, times, repeat configuration, and notes. (GET /schedules/{id})

When you turn writes on

22 write tools, off by default

Let Ruby manage time and schedules in Timeero instead of only reading them. This includes payroll actions, so only turn it on if you want Ruby acting on the clock.

An admin switches a connection to read-write in Settings > Integrations. From then on every write waits for a human’s approval before it leaves, by default, and every one lands in your audit log with what changed.

Update group

Changes data in the connected account. Update a group (rename or change its membership) Rename a group or replace who belongs to it. Supplying user_ids REPLACES the membership rather than adding to it, so read the group first and send the full intended list. Setting all_users to true puts every employee in the company into the group. (PUT /groups/{id})

Delete group

Changes data in the connected account. Delete a group Permanently delete a group from the company. The employees in it are not deleted, but the grouping and any manager visibility it provided are lost. (DELETE /groups/{id})

Create job

Changes data in the connected account. Create a job Create a new job for crews to clock into, e.g. when a new loss comes in. Check list_jobs for an existing match first so you do not create a duplicate for the same address. (POST /jobs)

Update job

Changes data in the connected account. Update a job (including closing it out) Update an existing job. Setting job_status to false deactivates the job, which is how a finished loss is closed out so crews stop clocking into it. `name` is required by the API even when you are only changing another field, so read the job first and send its current name back unchanged. (PUT /jobs/{id})

Delete job

Changes data in the connected account. Delete a job Permanently delete a job. Prefer update_job with job_status false to close out finished work: deleting a job discards it from the record, while deactivating preserves its history for job costing. (DELETE /jobs/{id})

Create task

Changes data in the connected account. Create a task Create a task employees can clock into within one or more jobs (e.g. demo, extraction, drying). (POST /tasks)

Update task

Changes data in the connected account. Update a task Update an existing task. `name` and `user_id` are required by the API even for a partial update, so read the task first and send its current values back unchanged. (PUT /tasks/{id})

Delete task

Changes data in the connected account. Delete a task Permanently delete a task from the company. (DELETE /tasks/{id})

Create timesheet

Changes data in the connected account. Create a timesheet entry (manual time entry) Add a completed or in-progress time entry for an employee, e.g. backfilling a shift a tech forgot to clock. To start a live shift instead, use clock_in_user. (POST /timesheets)

Delete timesheets

Changes data in the connected account. Delete timesheets in bulk Permanently delete one or more timesheet entries by id. Destructive and not recoverable through the API: confirm the exact ids with list_timesheets first, and prefer correcting an entry with update_timesheet over deleting it. (DELETE /timesheets)

Update timesheet

Changes data in the connected account. Update a timesheet entry (correct hours, job, or mileage) Correct an existing time entry: fix a clock-out someone forgot, move hours to the right job, or adjust mileage. `user_id` and `start` are required by the API even for a partial update, so read the entry first and send its current values back unchanged. (PUT /timesheets/{id})

Approve timesheets

Changes data in the connected account. Approve timesheets in bulk Mark one or more timesheet entries approved, the step that releases them for payroll. Approving is a payroll action: confirm the exact ids with list_timesheets (approved=false) and confirm the hours look right before calling this. (POST /timesheets/approve)

Why connect it to Ruby

Built for restoration, not bolted on.

Grounded answers

Ruby works from your actual Timeero data and cites what she found, so answers reflect your business rather than a stale export.

Reads by default

Every connection starts read-only. Ruby surfaces and drafts while your team takes the action; writes are opt-in per connection, human-approved by default, and always logged.

Managed, secure auth

Connect with one click. Tokens are encrypted and scoped per company; revoke access any time.

Knows restoration

Ruby understands jobs, claims, drying logs, and AR, so Timeero data lands in the right operational context.

Use it from anywhere

Connect once, then just ask.

Connect Timeero once in Ruby. Ask in the Ruby app, or bring the same secure connection into the assistant your team already uses.

Ruby

Ask in the Ruby app and get an answer grounded in Timeero and the rest of your connected stack.

Claude

Bring the same secure Timeero connection into Claude so it can answer with your live data.

ChatGPT

Use Timeero from ChatGPT with the same per-company, permissioned access Ruby uses.

Frequently asked questions

Do I need developer credentials to connect Timeero?

You paste an API key from your account in Settings > Integrations. There is nothing to build; Ruby stores it encrypted and scoped to your company.


Can Ruby change anything in Timeero?

Not unless you turn it on. Every Timeero connection starts read-only. An admin can switch a connection to read-write in Settings > Integrations; from then on each write Ruby makes waits for a human's approval before it leaves (by default; the same admin can switch that off) and is recorded in your audit log either way.


Is my Timeero data secure?

Credentials are encrypted at rest and access is scoped per company. You can revoke the connection at any time from Settings > Integrations, which immediately cuts Ruby off.


Can I use Timeero alongside my other tools?

Yes. Ruby reasons across every tool you connect at once, so she can tie Timeero to your CRM, accounting, email, and documentation in a single answer.