Scheduling your assistants can use. Authority you can control.

Connect in four steps

1. Open Workspace → Automation → Agent connections as the owner. Choose meeting types, expiry and whether new bookings need individual approval.
2. Copy the one-time token into your assistant’s secret settings. Use this site’s origin plus /api/mcp, with Authorization: Bearer followed by the token. Never place it in a URL or public code.
3. Discover meeting types and request availability. Submit propose_booking with the guest details, answers and a fresh UUID requestId. Reuse that ID only when retrying the exact same request.
4. Review pending proposals in the inbox. Approval is separate from execution. Call execute_proposal with the proposal ID, then get_receipt until the booking and email delivery states are known.

Connection details

POST /api/mcp with Content-Type: application/json and Accept: application/json, text/event-stream. REST clients can POST {tool, input} to /api/agent/call with the same Bearer token. Never share a token between unrelated assistants.

Remote MCP uses stateless Streamable HTTP with JSON responses. Your client must support a custom Authorization: Bearer header. Automatic OAuth connector setup is not available. Browser page tools are separate and never submit a booking.

A calendar your agent can read

Fetch calendar.md with your scoped Bearer token and eventId, from and to query parameters (UTC ISO timestamps, at most seven days). Each request reads current connected-calendar availability. The file includes available times, constraints, form fields, timestamps and a content revision. It excludes private calendar event details. Saved copies do not update themselves: fetch again before proposing a booking. External changes are visible on the next successful provider read; push subscriptions are not included.

Let any compatible assistant book—with your permission

Public profiles expose published meeting types and live availability. Visitor agents use /api/public/mcp or /api/public/agent without an owner key. Each request sends the guest a short-lived verification email. The guest reviews and approves the exact details before booking. Host access, event revisions, availability and quotas are checked again before the booking is saved.

Enable Public profile and verified agent booking in workspace Settings, publish your meeting types, and share /your-workspace-address. Your agent document lives at /your-workspace-address/calendar.md. The profile address currently uses the workspace slug.

Public requests are limited to 120 calls per IP per minute. Calendar reads and execution share 10 calls per IP and 30 per workspace per minute. New verification requests allow 3 per IP per 10 minutes, 3 per email per hour, 30 per workspace per hour and 1,000 platform-wide per day. Status polling allows 6 per request per minute. These fixed-window limits are shared across public HTTP and MCP; retryAfter reports when to retry. Existing booking and email plan quotas still apply.

Available tools

Shared limits, predictable retries

All agent endpoints share fixed one-minute limits: 120 requests per IP, 60 per access key and 180 per workspace. Calendar reads, coordination starts, booking proposals and execution also share 10 calls per key and 30 per workspace per minute. HTTP 429 includes Retry-After; MCP tool errors include retryAfter in seconds. Wait before retrying and avoid tight receipt-polling loops. Limits do not grant extra booking or email quota.

Preparation, written alternatives, and replacement meetings

Create a playbook from your real meeting types, then start a client journey. Give its ID to the assistant. get_journey returns preparation and a recommendation based on your explicit preference for written updates. Owners or admins complete checklists and stages. To move a future confirmed meeting created by the same connection, propose a replacement with rescheduleBookingId and the original guest and journey. Owner approval is always required. The original meeting stays in place until replacement processing succeeds.

Coordinate without exposing private calendars

start_coordination returns up to forty candidate times, a participant token, and an endpoint. The second assistant sends that token in an Authorization header to GET the candidates, then POSTs {accepted: [...]} to the endpoint. It can choose only offered times. get_coordination returns the intersection. The request expires in fifteen minutes, and neither step reserves or books a time.

Signed webhook contract

Owner-configured destinations receive booking.confirmed, booking.cancelled and booking.failed. Delivery is at least once, with up to eight automatic attempts. Deduplicate by X-Gatherly-Delivery. Verify X-Gatherly-Signature (v1= plus a hex HMAC-SHA256) over timestamp + "." + delivery ID + "." + the exact raw body, using the one-time signing secret. Reject timestamps outside a five-minute tolerance. Delivery order is not guaranteed. A 2xx response means the destination accepted the event, not that its downstream workflow completed.

Payloads contain the delivery ID, event type, occurrence time, booking ID, meeting-type ID, status, start/end, replaced-booking ID and calendar sequence. They exclude guest contact details and management tokens. HTTPS Zapier and Make destinations work directly; custom domains must be approved in WEBHOOK_ALLOWED_HOSTS by the platform operator. Redirects are never followed.