Developer API Beta Release
The API is planned as a thin workflow layer around model-ready artefacts, not as a black-box endpoint that hides preprocessing and provenance. The beta will follow the private-alpha learnings from real research workflows.
A contract around the workflow
A useful developer interface needs explicit schemas for structures, conditions, model versions, predictions, uncertainty, and review metadata. Stable identifiers matter as much as the score itself.
For molecular inputs, that may mean accepting a canonicalised SMILES or an SDF record while preserving the original string, stereochemical flags, salts, and source identifier. For optical rotation, wavelength, temperature, solvent, and concentration cannot be optional decoration; they define what the target means.
The first beta will prioritise predictable inputs and outputs over a large surface area. Teams should be able to reproduce a result and understand what changed between model versions.
Local-first by design
The planned API should support execution inside a team-controlled environment when the model and hardware allow it. Hosted services may be useful in some deployments, but they should not be the only path for sensitive molecular data.
Local execution also changes the engineering contract. The client needs a compatible runtime, model artefacts, resource limits, and a clear way to report unavailable hardware or unsupported operations. Local should describe where computation happens, not imply that every device can run every model.
Before the beta
The developer beta is planned for Q1 2027. Until then, access is being shaped through private-alpha conversations and concrete integration requests rather than an open public endpoint.
Before release, the interface needs contract tests for malformed structures, missing stereochemistry, incompatible conditions, model-version changes, and partial failures. A result that cannot explain why it was rejected is difficult to use safely in an automated research workflow.