My engineers will have to build against you. What do they actually get — SDKs, docs, sandboxes — and what is missing?

The full executive answer

What they get today, all verifiable in the repository: official SDKs in TypeScript and Python — the two languages enterprise integration teams actually use — typed against the API, with the TypeScript SDK carrying generated reference documentation. An OpenAPI 3.1 specification served from the API itself, covering every public endpoint, both auth schemes, the standard error envelope, and — unusually — the complete outbound webhook catalogue in the spec's webhooks section, so event payloads are documented in the same machine-readable contract as the endpoints. Idempotency keys for safe retries, stable machine-readable error codes for programmatic handling, and per-key scopes and rate limits your team can see and reason about.

The developer-experience conveniences that are honestly still thin, pre-launch: there is no self-service public sandbox tenant yet — pilot teams get a provisioned trial organisation, which serves the purpose but is concierge rather than self-serve; and the documentation portal is the OpenAPI contract plus SDK references rather than a rich guides-and-tutorials site. Both are roadmap, sequenced behind the first wave of real integrating teams so the guides answer questions actual integrators asked.

The design philosophy is contract-first — the OpenAPI document is the product's promise, and everything else generates from or validates against it — which matches how mature API programs are run and means your engineers can generate additional clients mechanically today rather than waiting on our roadmap.