SDK & API readiness
Runtime is in development. These guides explain design intent; they are not a released API or installation reference. Read the release policy →
No public SDK is released
Section titled “No public SDK is released”There are no public SDK coordinates, stable API definitions, generated clients, or version compatibility claims in these docs. Runtime is in development; the extension contract is not represented as final.
What an API contract should contain
Section titled “What an API contract should contain”A useful contract identifies inputs and outputs, nullability, validation, lifecycle, threading assumptions, cancellation, errors, and compatibility expectations. Language bindings need their own version and platform requirements.
Internal implementation details should not become public promises accidentally. A release review should identify the supported surface deliberately.
Keep examples executable
Section titled “Keep examples executable”A future SDK sample must compile from a clean environment, use the named release, and include a meaningful test. Networked samples should use synthetic data and isolated test credentials, with setup and cleanup described.
| Release artifact | Verification |
|---|---|
| API specification | Checked against implementation and negative cases |
| Client or SDK package | Resolved from the approved distribution channel |
| Sample project | Built and tested in CI against the named release |
| Compatibility statement | Supported combinations exercised explicitly |
Connect the pieces
Section titled “Connect the pieces”Connector authoring, management APIs, and developer tooling may have different lifecycles. Their compatibility should be tracked separately instead of assuming every component shares one version.
Read connector boundaries for extension design and migration planning for future compatibility changes.