Skip to main content
This walks through one complete task with the /v1 API: a session for a customer, their computer connecting, a task that asks a question and an approval, and the finished result with its replay. Every step has cURL, Node and Python. The Node code needs Node 18 or later (it uses the built-in fetch). The Python code needs requests (pip install requests). A single script with all of it is at the end of the page.
With an SDK the whole flow is about 15 lines: npm install guidinghand (JavaScript) or pip install guidinghand (Python). tasks.run() starts a task and answers its questions and approvals with your callbacks. This page shows the HTTP underneath.
1

Get an API key

Sign in at guidinghand.ai/console and open Settings → API keys. Create a key and copy it: it starts with gh_live_ and is shown once. Creating keys needs the admin or owner role in the org.
Every request sends it as a bearer token. The Node and Python snippets below share this small helper, which turns error responses into exceptions:
To try things without touching production billing, use https://dev.guidinghand.ai as the base URL with a key made in the dev console. Dev runs Stripe in test mode.
2

Create an agent (optional)

An agent holds your instructions, reasoning effort and the greeting the customer sees on the invite page. You can skip this step: every org has a default agent that works without setup.
agent_id becomes part of invite links, so it is lowercase letters, numbers and dashes. Creating an agent needs the admin role; an API key has it. An agent_id that already exists returns 409 conflict. See Agents.
3

Create a session and send the invite link

A session is one pairing code for one computer. Put your own ids in metadata so you can match the session to a ticket later.
Response
Send invite_url to the customer through whatever channel you already use: chat, email or the ticket. The page walks them through installing GuidingHand, granting the macOS permissions, and clicking Connect. The session_id is the code itself.session_token is for the older session-token API. It is shown once; you don’t need it for /v1.
4

Wait until the computer is connected

Tasks need status: connected. Either poll the session, or set up a webhook and wait for session.connected.
Once connected, device tells you the operating system (mac or windows), the computer’s name and its screen size.
5

Start a task

Describe the outcome in plain language. request_id is an idempotency key: if your request times out and you send it again with the same request_id, you get the same task back instead of a second one.
Response
One task runs at a time per computer. Starting another while one runs returns 409 conflict with the running task’s id in error.active_task_id.
6

Follow the task and answer what it asks

GET /v1/tasks/{task_id}/events returns the events after after. With wait_ms (up to 55000) it holds the request open until something new happens, so a simple loop gets every event as it happens. Pass the returned cursor as after on the next call, and stop when task.done is true.When the agent needs a person, task.pending is set and the task waits:
  • pending.type: "question": send its question_id and your answer. The customer usually sees the question on their screen too (pending.customer_can_answer) and can answer it there. The first answer is used; answering after them returns 409 with code: "already_answered" (or "not_pending" once that question has closed, say because they answered it and the agent has moved on), which just means it’s done.
  • pending.type: "approval": send its approval_id and a decision of approve or deny. The customer usually sees the request on their screen too (pending.customer_can_approve) and can allow it or not there. As with questions, the first decision is used, and already_answered or not_pending just means it’s done.
A response while the agent waits on a question looks like this:
Response
In a real integration the question usually goes to your support agent’s screen or to your own AI agent, not to a terminal prompt, or you leave it to the customer, who can answer it on their screen. answered keeps the loop from answering the same question twice if the next page arrives before the task moves on.
A task waiting on a question or approval doesn’t use agent minutes. Only running time is billed. See Tasks.
7

Read the result

When task.done is true, status is completed, failed or stopped. A completed task has the agent’s summary in result. A failed task has the reason in error. For a stopped task, the reason is the message of its last event (stopped), for example “Stopped by the person at the computer.”
Response
Add ?include=events to get every event with the task.
8

Open the replay

replay_url opens the task in the console: every screen the agent saw, with its cursor and clicks, next to the timeline of events. Anyone in the org can open it after signing in.To get the screens yourself, GET /v1/tasks/{task_id}/recording lists the frames and each frame’s url returns the PNG. See Recordings.

The whole thing

Save one of these and run it with GUIDINGHAND_API_KEY set. It uses the default agent, prints the invite link, waits for the computer, runs one task and answers questions and approvals from your terminal (the customer can also answer the questions on their screen). Set GUIDINGHAND_API_URL=https://dev.guidinghand.ai to run it against dev.

Next

  • Replace polling with webhooks.
  • Let your own LLM agent drive GuidingHand: AI agents.
  • Handle errors such as a computer that went offline or a plan limit.