Skip to main content

SchedKit Agent Tool Guide

API-FirstResponder — Signal anything. Coordinate everything.
SchedKit is built for agents. Atomic REST endpoints, API-key auth, zero session state. Your agent can check availability, create bookings, list them, and cancel them — all without any UI, OAuth dance, or server-side session to manage. This guide gets you from zero to a working tool-calling agent in one read.

Base URL & Auth

All requests and responses are JSON. No cookies. No sessions. Every call is self-contained.

Core Endpoints

GET /v1/availability

Check open time slots for an event type on a given date.
Query params: Response:

POST /v1/bookings

Create a booking. Always call /v1/availability first — don’t guess at slots.
Request body: Response:
If status is "pending", the host has requires_confirmation enabled. The booking is registered but not confirmed until they approve it. Tell the user.

GET /v1/bookings

List bookings. Useful for agents that need to surface existing bookings or check for conflicts.
Optional query params: event_type_id, status (confirmed | pending | cancelled), from, to (ISO 8601 dates). Response:

DELETE /v1/bookings/:id

Cancel a booking.
Response:

Tool Definitions

Copy-paste ready definitions for Claude and OpenAI. Define all four tools; your agent will pick the right one based on context.

Claude (Anthropic API — tool_use format)


OpenAI (GPT function-calling — functions format)


Example Agent Flow

Scenario: A user asks an AI assistant: “Book me a 30-minute call with the sales team for next Thursday. My email is jane@example.com.” The agent knows the event type ID from context or a prior lookup. Here’s the full exchange.
Step 1 — Agent checks availability Agent calls check_availability:
SchedKit responds:

Step 2 — Agent picks a slot and creates the booking Agent selects the first available slot and calls create_booking:
SchedKit responds:

Step 3 — Agent confirms to the user
✅ Booked. You’re on for Thursday, March 19 at 9:00 AM CST (30 min). A confirmation has been sent to jane@example.com. Booking ID: bkg_xyz789.

Handling requires_confirmation

If the host has approval enabled, the response looks like this:
The booking is registered. The host needs to approve it before it’s confirmed. Tell the user:
⏳ Your request is submitted. The host reviews bookings manually — you’ll get a confirmation email once they approve it.
Don’t tell the user the meeting is confirmed when status is "pending".

Best Practices

Always check availability before booking.
Don’t infer or guess at open slots from prior context. Availability is dynamic. Call the endpoint.
Pass the user’s timezone.
It’s optional in the API but you should always include it. Slots come back in UTC — without timezone context, the host can’t localize for the attendee.
Trust the API for rules enforcement.
Booking limits, buffer times, blackout dates, max bookings per day — all enforced server-side. Your agent doesn’t need to replicate that logic. If a slot isn’t returned by /v1/availability, it’s not available. If POST /v1/bookings returns an error, surface it to the user.
Handle errors cleanly.
A 409 Conflict means the slot was taken between your availability check and booking attempt. Re-check and offer the next available slot. A 422 Unprocessable Entity means bad input — check required fields.
Don’t double-book.
If your agent is booking on behalf of a specific attendee email, consider calling GET /v1/bookings first to check if they already have an upcoming booking for the same event type.
Use booking IDs for cancellations.
Store or surface booking.id after creation. That’s what you need for DELETE /v1/bookings/:id.

Quick Reference

Auth header on every request: x-api-key: YOUR_API_KEY
SchedKit API questions? → api@schedkit.net