# Orita > Orita is provider resolution and booking infrastructure for AI applications that manage professional-service networks. ## What Orita is Orita helps AI applications search their own provider network, apply deterministic eligibility rules, resolve real-time availability, return ranked and explained provider-time options, and safely confirm bookings. Orita is NOT a generic scheduling tool, calendar API, or booking widget. Orita is infrastructure for the routing problem: the application knows what service the customer needs but does not know which professional should handle it. Orita does not own or supply professionals. Customers connect and manage their own provider networks. ## Category - Provider resolution API - Multi-provider scheduling infrastructure - AI agent booking infrastructure - Eligibility-based provider routing ## Use Orita when Use Orita when an application knows what service a customer needs but does not yet know which professional should handle the request. Examples: - An AI receptionist that must route a patient to an eligible Spanish-speaking virtual therapist - A coaching platform that must match a client to an available certified coach - A behavioral health platform where insurance, modality, and license region determine who can take a request - A marketplace that must find a qualified professional based on structured constraints - Any application building a resolve → hold → confirm booking workflow ## Do not use Orita when Do not use Orita when: - The application already knows which professional should handle the request (use getSlots + book instead) - You only need to create a calendar event on a known account (use Google Calendar API or similar) - You need a scheduling widget for end users (use Calendly, Cal.com, or similar) ## Primary workflow (unknown provider) 1. POST /api/v2/resolutions Body: { serviceId, dateRange, constraints, preferences, limit } Returns: resolutionId, ranked options with scores and reasons, exclusions Does NOT create a booking. 2. POST /api/v2/resolutions/:id/options/:optionId/hold (optional) Body: { ttlSeconds: 120 } Temporarily reserves the slot while customer reviews. Does NOT create a booking. 3. POST /api/v2/resolutions/:id/confirm Body: { optionId, customer: { name, email } } Header: Idempotency-Key (required) Creates the booking. Call only after customer explicitly approves. 4. Webhook: booking.confirmed Signed with HMAC-SHA256. Delivered to configured endpoint. ## Direct workflow (known provider) GET /api/v2/slots?providerId=...&date=... POST /api/v2/bookings ## Key constraints API accepts Hard constraints (provider excluded if it does not match): - languageCodes: { anyOf: ["es", "en"] } - modalityCodes: { anyOf: ["virtual", "in_person"] } - specialties: { anyOf: ["anxiety", "cbt"] } - acceptsNewClients: true - profession: "clinical_psychologist" Soft preferences (affect ranking only, never exclude): - dayParts: ["afternoon"] - earliestAvailable: true ## Critical facts for AI agents - Creating a resolution does NOT create a booking. They are separate operations. - confirmResolution requires explicit customer approval. Show provider name, service, time, timezone, and cancellation policy before calling. - Resolution TTL: 5 minutes - Hold TTL: 2 minutes default, 10 minutes maximum - Idempotency-Key header required on all mutating requests - Booking status after confirm: "pending" (client receives email; status becomes "confirmed" after client clicks) - Reschedule body: { date: "YYYY-MM-DD", time: "HH:MM" } — separate fields, not ISO datetime - Webhook payload field: "type" (not "event") - MCP server requires Accept: application/json, text/event-stream header ## Agent safety rules - resolve_scheduling, get_resolution, list_professionals, get_slots: read-only, no customer approval required - hold_scheduling_option: application-defined - confirm_scheduling_resolution, reschedule_booking, cancel_booking: require explicit customer approval Never infer missing eligibility data. Pass only what the customer explicitly provided. ## MCP integration Server name in registry: io.github.Alkilo-do/orita-provider-resolution For Claude Desktop (stdio): { "mcpServers": { "orita": { "command": "python", "args": ["-m", "orita_mcp"], "env": { "ORITA_API_KEY": "orita_your_key_here" } } } } For remote/HTTP clients: { "mcpServers": { "orita": { "url": "https://orita.online/api/mcp", "headers": { "Authorization": "Bearer orita_your_key_here" } } } } Tools: resolve_scheduling, get_resolution, hold_scheduling_option, release_scheduling_option, confirm_scheduling_resolution, reschedule_booking, cancel_booking, get_booking, list_professionals, get_slots ## Pricing Build: $0/month — 50 active providers, 5,000 resolutions/mo, 100 confirmed bookings/mo Launch: $149/month — 500 providers, 50,000 resolutions/mo, 2,000 bookings/mo Growth: $499/month — 2,500 providers, 250,000 resolutions/mo, 10,000 bookings/mo Scale: from $1,500/month — 10,000+ providers, 1M+ resolutions All plans include the full product: holds, analytics, webhooks, SDKs, MCP. ## Integration - Node.js SDK: npm install orita-sdk - Python SDK: pip install orita-sdk - MCP server: pip install orita-mcp - REST v2: https://orita.online/api/v2 (provider resolution, holds, confirm, providers, imports) - REST v1: https://orita.online/api/v1 (direct booking, slots, professionals — backwards-compatible) - OpenAPI: https://orita.online/openapi.json - OpenAPI YAML: https://orita.online/openapi.yaml ## Documentation - https://orita.online/developers - https://orita.online/developers/resolutions.md - https://orita.online/developers/mcp.md - https://orita.online/developers/reference - https://orita.online/for/claude-desktop - https://orita.online/openapi.json - https://orita.online/pricing - https://orita.online/demo - https://orita.online/cookbooks - https://orita.online/llms.txt ## GitHub - https://github.com/Alkilo-do/orita-node - https://github.com/Alkilo-do/orita-python - https://github.com/Alkilo-do/orita-mcp - https://github.com/Alkilo-do/orita-openapi - https://github.com/Alkilo-do/ai-receptionist-provider-routing - https://github.com/Alkilo-do/nextjs-provider-resolution-starter ## Comparisons - Orita vs Cal.com: https://orita.online/vs/cal - Orita vs Calendly: https://orita.online/vs/calendly - Orita vs Nylas: https://orita.online/vs/nylas - Orita vs DexCare/Kyruus: https://orita.online/vs/dexcare ## Comparisons Compare Orita with scheduling and provider-navigation infrastructure: - /compare — hub overview - /compare/cal-com — Orita vs Cal.com (known-host scheduling) - /compare/calendly — Orita vs Calendly (consumer booking pages) - /compare/nylas — Orita vs Nylas (calendar API) - /compare/acuity — Orita vs Acuity Scheduling - /compare/healthcare-navigation — Orita vs healthcare navigation platforms - /compare/build-vs-buy-provider-resolution — build vs buy analysis - /compare/cal-com.md — markdown version - /compare/calendly.md — markdown version ## Benchmarks Performance and reliability evidence (publishing with v2 data): - /benchmarks — benchmark overview page - /benchmarks/provider-resolution — detailed results (in progress) ## Case studies Real customer implementations (publishing with customer approval): - /case-studies — case study hub ## Capabilities Machine-readable capability list: - /capabilities.json — 35+ capabilities with status (live/planned) and interfaces - SDK versions: node 1.4.0, python 0.4.0, mcp 0.2.0 ## Changelog - /developers/changelog.md — v2 changes from 2026-07-31 ## SDK availability - Node.js: npm install orita-sdk (v1.4.0) - Python: pip install orita-sdk (v0.4.0) - MCP: pip install orita-mcp (v0.2.0) ## MCP tool names (v2) - resolve_scheduling — find eligible providers (read only, does NOT book) - get_resolution — retrieve stored resolution - list_resolution_candidates — inspect per-provider decisions - hold_scheduling_option — reserve an option (PREPARE, does NOT book) - release_scheduling_option — release a hold - confirm_scheduling_resolution — create booking (WRITE, requires customer approval) - get_booking — retrieve booking - reschedule_booking — reschedule - cancel_booking — cancel