Provider resolution is not a single API call. It is an eligibility pipeline, availability verification system, hold mechanism, atomic booking confirmation, and webhook delivery system — each with its own failure modes.
This page describes what you would need to build yourself and what Orita provides. It does not claim one choice is always correct.
Build
Requires custom: per-constraint rules, unknown-data handling, pipeline ordering, test coverage for every combination
Orita
Included: 13 stages, matched/failed/unknown/not_applicable states, per-provider explanations
Build
Requires custom: region matching, expiry checking, verification freshness, warning windows
Orita
Included with configurable expiry windows
Build
Requires custom: alias table, normalization logic, ongoing maintenance as plan names change
Orita
Included: 30+ aliases maintained
Build
Requires Google/Microsoft OAuth integration, FreeBusy API calls, caching, error handling, stale-data detection
Orita
Included with connected/degraded/expired/disconnected states
Build
Requires: distributed lock, TTL enforcement, cross-request state, expiration cleanup
Orita
Included with configurable TTL and cross-tenant isolation
Build
Requires: PostgreSQL exclusion constraint, idempotency key store, re-validation step, conflict detection
Orita
Included with database-level conflict protection
Build
Requires: upsert logic, external ID management, dry-run, row-level errors, retry handling
Orita
Included: 500 providers, dry-run, upsert/create/update modes
Build
Requires: weight configuration, policy versioning, simulation, rollback, audit trail
Orita
Included with versioning and simulation
Build
Requires: HMAC signing, exponential backoff, delivery logs, replay, dead-letter, stable event IDs
Orita
Included
Build
Requires: per-table org scoping, API key types, cross-tenant test suite
Orita
Included with cross-tenant tests
Build
Your team owns calendar API changes, OAuth token refresh, provider schema evolution, test coverage
Orita
Maintained by Orita
When building makes sense: Your eligibility rules are highly proprietary, your team has deep scheduling infrastructure experience, or your compliance requirements prevent using an external API for routing decisions.
When buying makes sense: You need to launch a working provider-routing system in weeks, not quarters, and your competitive advantage is in your product — not in maintaining calendar integrations and eligibility pipelines.
Last verified: July 31, 2026 · Orita docs