Official client libraries for submitting verifiable transactions, reading Workstream configuration, and using Operon signature and session APIs.
All SDKs implement the coordinated 1.5.0 contract.
| Language | Package | Install |
|---|---|---|
| Go | github.com/operon-cloud/operon-sdk/go |
go get github.com/operon-cloud/operon-sdk/go@v1.5.0 |
| Node.js | @operoncloud/operon-sdk |
npm install @operoncloud/operon-sdk@1.5.0 |
| Python | operon-sdk |
pip install operon-sdk==1.5.0 |
| Java | cloud.operon:operon-sdk |
Maven/Gradle version 1.5.0 |
| .NET | Operon.Sdk |
dotnet add package Operon.Sdk --version 1.5.0 |
| Rust | operon-sdk |
Cargo version 1.5.0 |
These public guides are for server-side external M2M integrations using Operon-issued client credentials. Start with the Operon.Cloud Getting Started Guide for Console setup, platform concepts, and the end-to-end integration path.
Each language directory contains its own build and test commands. The coordinated release gate runs all suites, linters, package builds, and artifact inspections before tags or registry publication.
The Console guide explains how administrators configure Source Codes as stable lookup codes.
States and interactions use the same reference model:
- A code name, stored as
sourceCode, is administrator-configured and used by an integration to find the intended state or interaction. - A platform ID, submitted as
stateIdorinteractionId, is generated by Operon for that specific Workstream.
The retrieval shape is different: states are included in the Workstream response, while interactions are returned by the separate interaction catalog call. When a Workstream is cloned, its configured code names can remain the same while its state and interaction platform IDs change. Resolve both against the current Workstream configuration:
- Fetch the Workstream and resolve
READY_FOR_REVIEWto itsstateId. - Fetch the complete interaction catalog and resolve
CLAIM_REVIEWEDto itsinteractionId. - Submit correlation
case-123, 37 active seconds, and payload{"caseId":"case-123"}.
Only the resolved platform IDs are serialized into the transaction. Code names are discovery metadata, never transaction fields. Lookup trims whitespace, is case-insensitive, returns the first catalog match, and does not filter by status. A successful lookup can still be rejected by Client API for Workstream membership, ownership, or submission eligibility.
If an administrator changes a mapping, refresh the catalog and fail clearly when the code is no longer present; there is no implicit stale-ID fallback. An integration may instead store the current Workstream's platform IDs and submit those values directly. They are still Operon-generated IDs, not IDs owned by the integrating application.
| SDK | State code-name lookup | Interaction code-name lookup |
|---|---|---|
| Go | Workstream.FindStateBySourceCode |
WorkstreamInteractionsResponse.FindInteractionBySourceCode |
| Node.js | findWorkstreamStateBySourceCode |
findWorkstreamInteractionBySourceCode |
| Python | Workstream.find_state_by_source_code |
WorkstreamInteractionsResponse.find_interaction_by_source_code |
| Java | Workstream.findStateBySourceCode |
WorkstreamInteractionsResponse.findInteractionBySourceCode |
| .NET | Workstream.FindStateBySourceCode |
WorkstreamInteractionsResponse.FindInteractionBySourceCode |
| Rust | Workstream::find_state_by_source_code |
WorkstreamInteractionsResponse::find_interaction_by_source_code |
Both helpers resolve a configured sourceCode code name to the corresponding
Operon platform ID. State lookup searches the states included in the Workstream
response; interaction lookup searches the complete interaction catalog returned
by the interaction fetch. Neither lookup establishes Workstream membership or
submission eligibility; Client API remains authoritative.
Do not commit client secrets, bearer tokens, Central credentials, or signing material. Use environment variables or your deployment platform's secret store. Report security issues through the contact path at operon.cloud.
MIT. See LICENSE.