Appearance
Availability and scope
Mystro is live with invite-led developer access, as confirmed by the product owner. Onboarding establishes the supported integration surface, model route, and applicable protections for your environment. TEE and E2EE apply on supported routes; data boundaries identifies details that still need confirmation.
Live access and reference material
Request developer access to confirm your integration details. There is no public self-service provisioning promise in these guides.
The legacy HTTP API contract remains proposed. Its immutable releases, .invalid origins, and empty available-operations artifact are preserved for design reference. Live invite-led access does not promote those operations to available or make the examples executable.
Legacy contract release checks
The table and readiness checklist below describe the legacy proposed HTTP API contract. They do not describe the availability of every live Mystro integration. Local automated tests and a published contract are not proof of AWS provisioning, Auth0 configuration, customer onboarding, or Linux runtime containment.
| Surface | Verified evidence | Public availability |
|---|---|---|
| Documentation and read-only API explorer | HTTPS, deep links, mobile layout, no external requests, immutable spec hashes | Live documentation |
| Server SDK and customer ticket-tool example | Private package build; synthetic HTTP, signature, authorization and deduplication tests | Private source; not npm-published |
| Identity, keys, resources and run admission | Local PostgreSQL/SQLite tests; fail-closed composition ports | Proposed; cloud identity and cell acceptance checks required |
| Tools, files and webhook modules | Local signed operation, quarantine/scan and durable delivery tests | Proposed; real endpoint/storage/scanner and host checks required |
| Cancellation, deletion and restore | Coordinator and recovery contracts; missing adapters must fail closed | Proposed; complete invalidation and restore-drill evidence required |
| Provider execution and isolation | Bounded runtime design and local fixtures | Proposed; actual Linux containment and supplier metering verification required |
| Managed OAuth, schedules and persistent agent memory | Future contract inventory | Deferred |
Operator readiness checks
A readiness check must verify configured services, not merely the presence of environment variables. Before an environment can be marked ready, collect evidence for identity-provider login/MFA, authoritative database and cell binding, encrypted storage, approved outbound broker, model/provider access, and applicable quotas. Refresh the current serving generation on requests and dispatches.
Before a public pilot, verify rate limiting, actor revocation during a stream and a pending approval, control-plane-first admission/cancellation, lost-response reconciliation, malware quarantine, webhook replay and secret rotation, deletion journal replay after restore, backup expiry, and measured-versus-reserved cost attribution. A missing dependency must return an unavailability failure; it must not produce a success-shaped stub.
Individual proposed operations may still require composition work, including deletion-job adapters, usage-ledger records, quota administration, retention settings, audit retrieval, and public tenant/service-actor management. Operators must test those operations on the actual release candidate. The downloadable openapi-available.json deliberately contains no live operations until required cloud and runtime checks pass.
Changing a capability to available requires fresh production evidence and an explicit release update. Publishing these docs does not change that state.