Compatibility surface

Small text responses for older clients.

Legacy exposes a narrow read-only bridge for systems that need predictable HTTP text output instead of full JSON, ICS, WebCal, or browser-oriented pages. New integrations should prefer OpenAPI or I/O.

Isolated transport

HTTP ends at the legacy boundary.

Modern Super-Calendar pages, APIs, accounts, and private data remain HTTPS-only. Plain HTTP is accepted only on the isolated legacy hostname for fixed public text routes. The bridge then requests an allowlisted I/O projection from the main API over HTTPS.

Legacy client
  -> http://legacy.super-calendar.io/weather-summary
  -> fixed allowlist, GET or HEAD, no credentials
  -> https://super-calendar.io/api/weather/io/...
  -> small public text response
BoundaryPolicy
Main applicationHTTPS only.
Legacy hostnameHTTP compatibility plus an HTTPS mirror.
MethodsGET and HEAD only.
DataPublic low-level text only.
CredentialsNever accepted or forwarded.
RoutingFixed allowlist. No arbitrary URL or path forwarding.

GET only

Legacy routes are read-only projections. They do not create accounts, spaces, notes, bookings, or private data.

Scoped paths

Only documented allowlisted paths are served. Arbitrary proxying is not part of the contract.

Plain output

Responses favor compact text with short cache windows and stable encoding for low-level consumers.

Priority ladder

Pick the highest-level surface your client can use.

Surface Best for Entry
OpenAPIModern API clients and generated SDKs./api/docs
I/ONode, row, cell, CSV, TSV, NDJSON, and text projections./io/
LegacyCompatibility systems that need tiny text reads./api/legacy
AgentsMachine-readable site and integration guidance./agents/

Examples

Current public compatibility routes.

GET http://legacy.super-calendar.io/health.txt
GET http://legacy.super-calendar.io/weather-summary?charset=0
GET http://legacy.super-calendar.io/exchange-summary?charset=1
GET http://legacy.super-calendar.io/moon-summary?charset=2

The canonical machine-readable contract is available at /api/legacy.

Migration

Move to I/O when you can.

I/O gives the same low-level feel with stronger addressing, more formats, and direct resource manifests. Legacy exists for compatibility, not for new feature design.

Open I/O Docs Open OpenAPI Docs Plain text readme