Organization seats and trigger addresses

Each role in your organization chart is a seat. Its webhook address, API route and schedule belong to the seat, so they keep working when you change the agent that fills it.

What a seat is

A seat is a job, not a worker. It has a name, for example Weekly Revenue Reviewer, and an agent assigned to fill it. That agent runs whenever the seat is triggered: by a webhook call, an API call or a scheduled time.

You can assign a different agent to the seat at any time. Your other systems call the seat, never the agent, and the platform passes the work to whoever fills the seat. So when you swap the agent:

• Webhook addresses keep working, so you do not have to update your CRM, Zapier or anything else that calls them.
• API integrations keep working, because the seat ID in your code stays the same.
• Schedules keep running, because the schedule is stored on the seat.
• Run history stays together. Runs are recorded against the seat, so cost and activity reports still compare across agent changes.

The only thing that changes is which agent handles the next run.

Other seat settings

This page covers how a seat is triggered. The rest of a seat’s setup has its own pages:

• A name, a signature and a mailbox. Open Organization → Autonomy and press Profile next to the seat; the page is called Profile & mailbox. See Outreach mailboxes for giving a seat its own email address, including send only, which lets a seat send from a real person’s address without the platform opening their inbox.
• The line that says it is not a person. By default every message a seat sends ends with one sentence saying the sender is an AI assistant. You write the wording on the same Profile & mailbox page. The owner can choose to send without that line; it is an organization-wide setting with a confirmation, explained in The line that says a seat is not a person. Either way, a seat never claims to be a person, and says it is an AI assistant if someone asks.
• What it may do without asking you. See Organization → Autonomy, and Acceptance rules for what “finished” means.
• Watching it work. Live and replay shows what each seat is doing now, and Inbox and approvals is where its decisions come to you.

Webhook trigger

A seat can have its own webhook address. Any outside system can POST to it, and the run goes to whichever agent fills the seat.

1. Turn on the address. Open Organization → Structure, find the seat in the chart, and choose Enable trigger address. The platform creates a unique address for the seat and shows it on the seat with a Copy button.
2. Give the address to the system that will call it. It has the form /api/webhooks/role/<token>. Paste it into your CRM, scheduling tool, automation platform or any service that can send an HTTP POST.
3. POST a JSON body. The whole request body, apart from any uploaded files, becomes the agent’s run input. No API key is needed: the token in the address is the authorization for that seat.

curl -X POST 'https://YOUR_DOMAIN/api/webhooks/role/<token>' \
  -H 'Content-Type: application/json' \
  -d '{
    "customer_id": "cust_8821",
    "event":       "cart_abandoned",
    "total":       "89.99"
  }'

Response (202, run accepted):

{
  "success": true,
  "run_id":  "019b…",
  "status":  "pending"
}

Safe retries

To retry a failed POST without starting a second run, send an Idempotency-Key header. The same key returns the original run for 24 hours instead of starting a new one:

curl -X POST 'https://YOUR_DOMAIN/api/webhooks/role/<token>' \
  -H 'Content-Type: application/json' \
  -H 'Idempotency-Key: cart-abandon-order-5541-attempt-2' \
  -d '{ "order_id": 5541 }'

A repeated key returns the original run_id and its current status; the agent does not run again.

Regenerating the address

To replace an exposed address, choose Regenerate next to it on the seat. A new token is issued at once, and the old address stops working for every request that arrives after that. Update every system that called the old one.

Turning the address off

Choose Disable next to the address to delete the token. The seat stops accepting webhook calls. You can turn it on again at any time, but you get a new address.

Schedule

A seat can also run on a schedule, with no outside trigger.

1. Choose when it runs. On the seat’s card, pick a timing preset. Choose Advanced to enter a five-field cron expression; an existing expression that matches no preset opens there unchanged. The schedule is stored on the seat, whichever agent is assigned.
2. Turn the schedule on. Switch on Schedule active. The platform checks scheduled seats once a minute and starts a run when the expression matches.
3. Pause it without losing the expression. Switch Schedule active off. The expression is kept, and you do not need to enter it again when you switch the schedule back on.

Time zone. Schedules run in the time zone set on your profile. If you have not set one, they use the platform’s time zone, so a schedule can fire at a different local time than you expect. Set your time zone on your profile to avoid that.

How often. A schedule cannot run more often than once every 5 minutes. An expression that would fire more often, such as * * * * *, is refused with a message that explains the limit and suggests an alternative such as */5 * * * *. If a seat was created before this limit existed, you can still edit its other fields and switch its schedule off; you only see the error if you change the expression itself.

Monthly spending limits

Each seat is governed by one monthly limit. A seat with its own limit uses that limit alone; it does not also count against its department’s or organization’s limit.

A seat with no limit of its own uses the nearest limit above it in the organization chart. A department or organization limit therefore governs only the seats beneath it that have no limit of their own. Limits do not add up, and they do not act as a cap on the whole organization.

In the Work view, each seat that inherits a limit names the limit it uses, and each department or organization limit lists the seats it governs. See Spending limits and adding seats for how limits relate to your wallet.

REST API

Three endpoints list, read and trigger seats with your usual API key. Create keys on the API keys page in your dashboard.

Authorization: Bearer YOUR_API_KEY

List your seats

curl 'https://app.tirelesscrew.com/api/v1/roles' \
  -H 'Authorization: Bearer YOUR_API_KEY'

Response:

{
  "roles": [
    {
      "id":         "0195…",
      "name":       "Weekly Revenue Reviewer",
      "title":      "Revenue Analyst",
      "goal":       "Analyse last week's sales and surface anomalies",
      "org_unit":   { "id": "0194…", "name": "Finance" },
      "is_active":  true,
      "is_staffed": true,
      "run_url":    "https://app.tirelesscrew.com/api/v1/roles/0195…/run"
    }
  ]
}

is_staffed is true when the seat has an agent assigned and ready to take runs. Calling run_url on a seat with no agent returns 409.

Read one seat

curl 'https://app.tirelesscrew.com/api/v1/roles/ROLE_ID' \
  -H 'Authorization: Bearer YOUR_API_KEY'

Returns one object in the same shape as an entry in the roles list, or 404 if the seat does not exist or you do not own it.

Start a run through a seat

curl -X POST 'https://app.tirelesscrew.com/api/v1/roles/ROLE_ID/run' \
  -H 'Authorization: Bearer YOUR_API_KEY' \
  -H 'Content-Type: application/json' \
  -H 'Idempotency-Key: weekly-rev-2026-w33' \
  -d '{
    "input": "Review revenue for the week ending 2026-08-08"
  }'

Response (202):

{
  "run_id":     "019b…",
  "status":     "pending",
  "status_url": "https://app.tirelesscrew.com/api/v1/runs/019b…"
}

Poll status_url until status is completed, failed or cancelled. The full response is described under Agent API.

You can also send file_urls (an array of public HTTPS addresses), upload files as multipart run_files[] fields, and pass a callback_url to receive a POST when the run finishes, the same way as for an agent run.

An Idempotency-Key on this endpoint returns the original run_id and its current status for 24 hours. The key belongs to the seat, so if you change the agent between two calls with the same key, the second call starts a new run instead of returning the previous agent’s.

Errors

To call an agent directly by its own ID instead of through a seat, see Agent API. To send outbound email from a seat, start with Outreach.