Official Invoance SDKs, Now in Eight Languages
The Invoance client libraries now cover eight languages. Every SDK anchors events, documents, and AI outputs to an append-only ledger, signs them with your tenant's Ed25519 key, and verifies signatures entirely client-side — so the proof holds up whether or not anyone trusts Invoance. Here is what shipped and how to start.
Eight official SDKs, one proof layer
Invoance gives your application a proof layer: every event, document, and AI output you send is canonicalized, hashed, signed with your tenant's Ed25519 key, and written to an append-only ledger that anyone can verify — no Invoance account required.
Today that layer is available as official, typed client libraries in eight languages: Python, Node.js, Go, Rust, Java, Ruby, .NET, and PHP. Every SDK exposes the same surface — events, documents, AI attestations, traces, and audit logs — so the API you learn in one language is the API you already know in the rest. No vendor lock-in, no bespoke wrappers to maintain.
Key insight. Same methods, same wire format, same verification in every language. Pick the SDK that fits your stack, not the other way around.
Start in three lines
Install the client for your language, set your API key, and anchor your first record. The SDK handles canonicalization, hashing, and encoding for you.
pip install invoance # Python
npm install invoance # Node.js
go get github.com/Invoance/invoance-go # Go
cargo add invoance # Rust
gem install invoance # Ruby
composer require invoance/invoance # PHP
dotnet add package Invoance # .NET
# Java (Maven / Gradle): com.invoance:invoanceAnchor an event
A quick example in Node.js — every other SDK follows the same shape. The returned record is hashed, signed, and immutable the moment it lands.
import { InvoanceClient } from "invoance";
const client = new InvoanceClient(); // reads INVOANCE_API_KEY
const event = await client.events.ingest({
eventType: "policy.approval",
payload: { policy_id: "pol_001", decision: "approved" },
});
console.log(event.event_id); // signed, anchored, independently verifiableProof you can verify yourself
The part that matters: verification does not depend on trusting Invoance. Each SDK ships the same client-side Ed25519 verification the backend uses, so you can recompute an event's canonical hash and check its signature offline, against the tenant's published public key.
That means an auditor, a customer, or a regulator can confirm a record is authentic and unaltered without an Invoance account and without access to your systems. Tamper-evident by construction, independently verifiable by anyone.
Get the SDKs
All eight libraries are published to their native registries and open-sourced under the Invoance GitHub organization. Full quickstarts, per-method references, and endpoint docs live in the developer docs. More languages are on the roadmap — tell us what you need.
- Developer docs & quickstarts— Per-language SDK references, endpoints, and verification guides.
- SDK source on GitHub— Every official client library, open source under the Invoance org.
Anchor every AI input and output as tamper-evident proof at generation time, one API call, no model changes.
Recommended
How to Export Audit Logs for Enterprise Customers: Signed, Verifiable, Audit-Ready
Any system can dump audit logs to a CSV. The problem is that a CSV is a file you are asking an auditor to trust. This guide shows how to export audit logs as signed, independently verifiable records: paginated from a real API, with a per-record Ed25519 signature and a gapless sequence that proves nothing was dropped or altered.
How to Prove Your AI Did What It Said: A Developer's Guide to Verifiable AI Outputs
Your AI's output is gone the moment it returns. Logs aren't proof. This guide shows how to attach a cryptographic receipt to every model call, in three lines of code, with a public URL anyone can verify, no Invoance account required.
Invoance Audit Logs vs WorkOS Audit Logs: An Honest Comparison
Both products record who did what in your customers' accounts, and both ship a portal, streaming, and exports. The fork in the road is what happens after an event is stored: WorkOS asks your customer to trust the record, Invoance signs it so they can check. A feature-by-feature and price-by-price comparison, with sources.
WorkOS Audit Logs Alternatives: A Buyer's Guide
Most WorkOS alternatives lists are identity-platform roundups where audit logs are one checkbox among twenty. If what you actually need is the audit log, the field looks different. Here is how to pick by the job you are hiring for, what each path costs, and the one question that separates audit log products fastest: can anyone verify the record?