SDK reference

Availability — read this first

None of these SDKs is published yet, and the source repository is private. They are built and tested, and the APIs below are real, but today you cannot install any of them from a public registry: edssa-core is not on crates.io, there is no edssa package on PyPI, and edssa-io/edssa-go / edssa-io/edssa-py do not exist as public repositories. Every Source: link on this page therefore resolves only for people already inside the repo.

This page is an API reference, not an installation guide. Treat the snippets as a description of the surface you get once distribution opens, and the package names as intended rather than claimed.

If you need to integrate today, write to support@edssa.io. SDK access is arranged per customer under the licence, because the code is BSL 1.1 and part of it is under a patent filing hold.

If you are an Autopliance subscriber, you do not need any of this to get value from your plan — your plan includes hosted traffic against your own fleet, which is what produces the chain your reports are generated from. See Autopliance — getting started.

Four SDKs exist in-tree: Rust, Go, Python and Node/TypeScript.

Rust — edssa-core

The native engine crate. Anything you can do at the CE binary layer, you can do directly from Rust.

Not on crates.io — cargo add edssa-core does not resolve. Inside the repo it is a path or git dependency.

#![allow(unused)]
fn main() {
use edssa_core::{verify_token, ActiveEdssaState, encode_sub_id};

fn check(token: &[u8; 64], state: &ActiveEdssaState<64>) -> bool {
    verify_token(token, state).accepted
}
}

• Source: code/edssa-core/ in the (private) monorepo.
• Feature flags: the enterprise umbrella (default-on) gates the oracle, orbit, relay, swarm, and weaver modules (plus their re-exports, e.g. MedianOf3). CE consumers should set default-features = false; the CE-visible surface (verify_token, construct_token, ActiveEdssaState, EdssaCore, EdssaRouter, RatchetState, encode_sub_id / decode_sub_id, SUB_ID_SLOTS, SUB_ID_MAX) stays available.
• Stability: the engine API (verify_token, construct_token, ActiveEdssaState, EdssaCore, EdssaRouter) is the patent surface. Other modules are evolving and may change between minor versions.

Go

Intended import path github.com/edssa-io/edssa-go — that repository does not exist publicly, so go get cannot resolve it. The code lives in-tree at code/sdk/go/.

cgo binding over edssa-core-ffi (Phase-8 batch 4 substrate). The Go SDK statically links the C ABI, so consumers don’t ship the edssa-core-ffi shared library separately.

import "github.com/edssa-io/edssa-go"

state, err := edssa.NewStateFromSeed(seed, edssa.Balanced)
if err != nil { ... }
defer state.Close()

ok := state.Verify(token)

• Source: code/sdk/go/ in the (private) monorepo. The public edssa-io/edssa-go mirror is not published yet.
• Underlying C ABI: code/edssa-core-ffi/ in the (private) monorepo. The committed header (include/edssa_core.h) is the source of truth for the Go binding.

Python

Package name edssa-sdk (import edssa_sdk) — not on PyPI, so pip install edssa-sdk fails today. Do not substitute a similarly-named package from the index: none of them is ours. The code lives in-tree at code/sdk/python/.

A ctypes binding over the same edssa-core-ffi C ABI as the Go and Node SDKs — pure Python, no native-addon build, no third-party dependencies. It loads the prebuilt libedssa_core_ffi.{dylib,so} at runtime. Same engine, same wire format. (Earlier revisions of this page said “PyO3 wrapper”, which was ADR-001 / D-6’s plan; what was built is ctypes, chosen so the SDK needs no compile step at install time.)

from edssa_sdk import load

edssa = load()                # finds libedssa_core_ffi, or pass a path
with edssa.new_state(seed, chaff_count=16, threshold=33) as st:
    ok = st.verify(token)     # token: 64 raw bytes (decode_hex for wire form)

• Source: code/sdk/python/ in the (private) monorepo. The public edssa-io/edssa-py mirror is not published yet.
• Pure Python, CPython 3.8+; there are no wheels to build. What ships beside it is the platform’s edssa-core-ffi shared library.

Node / TypeScript

Built, not published. A koffi FFI binding over the same C ABI as the Go SDK, in-tree at code/sdk/node/. (Earlier revisions of this page said Node was deferred to Phase 9 per ADR-001 / D-6; it was subsequently built, and the page had not caught up.)

Choosing between SDKs

Minting: what actually works today

This page previously said the SDKs “handle minting only”. That was wrong: until 2026-08-08 the C ABI every SDK wraps exported edssa_state_new and edssa_verify and nothing else, so none of the SDKs could produce a token.

There are now two real paths, and for a hosted plan the first is the one you want:

1. The hosted mint API — POST /api/v1/fleets/<fleet>/mint on app.edssa.io, authenticated with an API token from Connect your systems in the app. No SDK, no download, no build: you get an X-EdSSA-Token header back and present it. Any language with an HTTP client works. Present it immediately — a credential is good for about two ratchet intervals, not stored like a bearer token.
2. Minting in-process — edssa_credential_at_epoch / edssa_credential_mint in the C ABI, wrapped by the Go, Python and Node SDKs. This exists in-tree and is not published: the SDKs are not on any registry and the repository is private, so this path is available only under a per-customer source licence. See the availability note at the top of this page.

The CE binary is the integration story for non-Rust services that don’t want a build-time SDK dep — drop the sidecar in, point your service at it, and your service stays language-agnostic.

That story has the same availability caveat as the rest of this page: the CE image is not on Docker Hub and binary downloads are not open yet, so the sidecar is built from source rather than pulled. See the Quickstart, which builds it locally.