[TimeZest] List agents — the individual TimeZest users who can be scheduled. Each carries an opaque prefixed id (agnt_...), name, email and status. Paging is CURSOR-based with a fixed page size of 20 and no size parameter: the envelope is {object:"list", next_page, previous_page, data:[...]} where next_page/previous_page are ABSOLUTE URLs or null, and results are ordered newest-first by creation date (not changeable). To page forward, take the starting_after value from next_page and pass it as startingAfter. Optional TQL filter, e.g. agent.name_LIKEjohn.

[TimeZest] List resources — the UNION of agents and teams, i.e. everything that can be scheduled, in one call. Prefer this over calling timezest_list_agents and timezest_list_teams separately when you just need something schedulable and do not care which kind it is; each item's id prefix (agnt_ or team_) tells you what you got. Same cursor paging as the other lists (fixed page size 20, newest-first). Optional TQL filter.

[TimeZest] List teams, including each team's type — the scheduling behaviour that decides how TimeZest picks among the team's members. Each carries an opaque prefixed id (team_...) and name. Use this when an appointment should go to a group rather than one named person. Same cursor paging as the other lists (fixed page size 20, next_page/previous_page absolute URLs or null, newest-first). Optional TQL filter.

[TimeZest] Create a scheduling request. DESTRUCTIVE because it REACHES A HUMAN: with triggerMode "pod" TimeZest runs the normal workflow, which EMAILS THE END USER a booking link, and the TimeZest API publishes no cancel or delete — an email cannot be unsent, and undoing a booking means sorting it out in TimeZest or with the customer directly. triggerMode is REQUIRED and never defaulted, so sending is always a deliberate choice: pass "pod" to fire the workflow as though the request had been created in the PSA pod/insight, or "generate_url" to create the request WITHOUT that workflow (in TimeZest's default configuration generate_url does nothing, which makes it the safe option when you only want the record). Provide the rest as a JSON object body: the appointment type id from timezest_list_appointment_types, the end user's details, and the agent/team/resource id from the directory tools. Optionally include associated_entities to bind the appointment to the ticket it came from — TimeZest accepts EITHER a single object OR an array, and StackJack passes whichever you send through unchanged; known types include connectwise_psa/service_ticket, connectwise_psa/project_ticket, connectwise_psa/company, connectwise_psa/contact, autotask/ticket, autotask/company, autotask/contact, halo_psa/ticket, halo_psa/user, service_now/incident, service_now/problem, service_now/change_request and service_now/sn_customerservice_case. Do NOT put trigger_mode in the body: it is filled in from the triggerMode argument, and a body carrying a DIFFERENT value is rejected before the request is sent rather than one silently winning. A read-only TimeZest API key is refused here with a permission error while every read tool keeps working — that means the key needs replacing with a read/write one, not that the connection is broken.

[TimeZest] Retrieve ONE scheduling request by its opaque id, returned as a bare object rather than the list envelope. Use this to check what became of a booking you created — in particular whether status has moved from new to sent (the end user has been emailed) and on to scheduled with a selected_start_time. Ids are opaque prefixed strings from timezest_list_scheduling_requests or from the create call's response; never construct or parse one.

[TimeZest] List appointment types — the templates that define an appointment's duration and which workflow runs when it is booked. Each carries an opaque prefixed id (apty_...), name and duration. Read this FIRST before booking: the id returned here is what timezest_create_scheduling_request needs to know WHAT is being scheduled. Same cursor paging as the other lists (fixed page size 20, {object:"list", next_page, previous_page, data:[...]}, newest-first). Optional TQL filter.

[TimeZest] List scheduling requests — appointments asked for, in whatever state they have reached. Status tells you how far each one got: new (created, NO email sent to the end user yet), sent (TimeZest has emailed the end user at least once), scheduled (the end user picked a time), cancelled, and expired. Each item carries the end user's details, the selected start time when one exists, and the associated_entities linking it back to a PSA ticket. Filter by TQL, e.g. scheduling_request.end_user_email_EQsomeone@example.com or scheduling_request.selected_start_time_GTE2026-08-13. Same cursor paging as the other lists (fixed page size 20, newest-first).