Changelog

2026-06-02 — Event reminders

Events can now fire timed reminders. Set a reminders array on an event (minutes before start_time, e.g. [10, 1440] for 10 minutes and 1 day before — max 5 entries, each 1–40320 minutes). Calendars carry a default_reminders field that events inherit when they don’t set their own; resolution falls back to a system default of [10]. A null field inherits the level above, while [] means explicitly no reminders. Each reminder fires a new event.reminder webhook at start_time minus the offset (confirmed events only), and reminders are emitted as VALARM components in the iCal feed so calendar apps display the alarm.

2026-05-11 — Simplified API keys

Removed test mode. Keys no longer distinguish between live and test. Each org has a single API key prefix (chr_sk_*); all requests count toward quotas uniformly. Legacy chr_sk_live_* keys continue to authenticate without change. The mode field has been removed from POST /v1/auth/keys and the is_test field has been removed from all resource schemas.

v1 — Agent-native scheduling

April 16, 2026

v1 extends the Chronary API for true agent-to-agent coordination: agents can now advertise operational state on their calendars, query a single endpoint for temporal context, declare availability rules without placeholder events, and negotiate meeting times through a first-class proposal protocol.

Added

• Temporal context — GET /v1/calendars/:id/context returns the current event, next upcoming event, the last three ended events, the next events starting within 24 hours, and the calendar’s agent_status in a single call
• Agent status — calendars now expose an agent_status field (idle / working / waiting / error) so agents can advertise their operational state to other agents, dashboards, and human subscribers
• Scheduling proposals — full multi-agent negotiation protocol under /v1/scheduling/proposals with create, respond (accept / decline / counter), resolve, and cancel endpoints; resolved proposals emit a confirmed event (spr_ prefix IDs)
• Availability rules — per-calendar PUT / GET / DELETE /v1/calendars/:id/availability-rules for working hours and buffer times, applied automatically by the availability engine
• Temporal holds — tentative event reservations via POST /v1/calendars/:cal_id/events with status=hold, plus PUT /v1/events/:id/confirm and PUT /v1/events/:id/release for promoting or releasing a held slot. Holds carry a TTL (hold_expires_at) and a priority (hold_priority) that pre-empts lower-priority overlapping holds
• Lifecycle webhooks — new event.started, event.ended, event.hold_created, event.hold_expired, event.hold_released, event.hold_confirmed, proposal.created, proposal.responded, proposal.confirmed, proposal.expired, and proposal.cancelled event types for real-time coordination

v1.0 — Public Beta Launch

April 4, 2026

The initial public beta of Chronary, a calendar-as-a-service platform purpose-built for AI agents.

Core API

• Agent CRUD — Create, read, update, delete, and list agents with agt_ prefixed IDs
• Calendar CRUD — Full lifecycle management for calendars (cal_ IDs), linked to agents
• Event CRUD — Create, read, update, delete, and list events (evt_ IDs) with support for single and recurring events
• Availability engine — Query free/busy slots across one or more agents with configurable duration, buffer times, and working hours
• Usage endpoint — GET /v1/usage returns current consumption against plan limits

Integrations

• iCal feeds — Generate read-only iCal feed URLs for any calendar, consumable by Google Calendar, Apple Calendar, Outlook, and other calendar apps
• iCal subscriptions — Subscribe calendars to external iCal URLs; events sync automatically on a recurring schedule
• Webhooks — Subscribe to calendar and event lifecycle events with HMAC-SHA256 signed payloads and automatic retry with exponential backoff
• MCP server — Model Context Protocol server exposing 9 tools, sharing the same Worker and service layer as the REST API

Platform

• API key authentication — Keys use the chr_sk_* prefix, hashed with SHA-256 before storage
• Rate limiting — 10 requests per second per key with Retry-After headers
• Monthly quotas — Plan-based limits on agents, calendars, events, API calls, webhook deliveries, and availability queries
• Console dashboard — Web UI at console.chronary.ai for account management, API key generation, and usage monitoring
• Structured error handling — Consistent error response format with machine-readable type field and request_id on every response for debugging

Infrastructure

• Globally distributed — sub-50ms response times worldwide
• Durable, auto-scaling storage — primary data store with connection pooling
• Observability — structured logging and uptime monitoring
• Test coverage — 327 tests with 90%+ line, branch, function, and statement coverage