API FAQ
Common questions about the Invoance API, authentication, anchoring, verification, and rate limits.
Getting started
The Invoance API is a REST API that lets you hash, sign, and timestamp any business event, document, or AI output. Every record is written to an append-only ledger and can be independently verified by anyone, no Invoance account required.
Sign in to your dashboard at app.invoance.com, navigate to Profile → API Keys, and click Create Key. Give it a name (e.g. "production" or "staging"), and copy the key immediately, it is only shown once. Set it as INVOANCE_API_KEY in your environment, or pass it directly when initializing the SDK client.
Just an API key and one of our SDKs. Install for your language — 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), or com.invoance:invoance for Java — set your key, and you can anchor your first event in three lines of code. See the SDKs page for a full quickstart.
Official SDKs for Python, Node.js, Go, Java, Ruby, Rust, .NET, and PHP. Every endpoint is also documented with raw cURL examples if you prefer another language.
Yes. Every new organization gets a generous free allocation for testing. Check the Pricing page for current limits. All anchored records on the free tier are production-grade, there is no separate sandbox environment.
Authentication & security
All requests use Bearer token authentication. Include your API key in the Authorization header: Authorization: Bearer invoance_live_xxx. Keys are scoped to your organization and can be rotated at any time from the dashboard.
Yes. You can create multiple keys per organization, useful for separating production and staging, or giving different services their own keys. Each key can be independently revoked.
All traffic is encrypted in transit via TLS. Payloads are hashed with SHA-256 and signed with Ed25519 before being written to the ledger. The original payload content is not stored, only the cryptographic proof.
Events & anchoring
An anchored event is any piece of data you send to the API that gets hashed (SHA-256), signed (Ed25519), timestamped, and written to the immutable ledger. Once anchored, the record cannot be altered or deleted.
Business events (approvals, state changes, audit actions), documents (any file type, the SDK handles hashing and encoding), and AI outputs (model name, prompt, and response bound into a single signed record).
Idempotency ensures that sending the same request twice doesn't create duplicate records. Yes, pass an Idempotency-Key header with a unique value per request. If a duplicate key is received within 10 minutes, the API returns the original response.
Event payloads are limited to 1 MB of JSON. Document anchoring supports files up to 50 MB, the SDK streams and hashes them without loading the entire file into memory.
Verification & proof
Anyone can verify a record by recomputing the SHA-256 hash of the original payload and validating the Ed25519 signature against the organization's public key. No Invoance account is needed, verification is fully independent.
Your public key is served at https://api.invoance.com/keys/{your-domain} and is also available in your dashboard under Settings. Third parties use this key to verify your records.
Traces group related events, documents, and AI attestations into a single verifiable process proof. For example, an invoice approval flow might include events for creation and approval, an anchored contract document, and an AI risk assessment, a trace bundles them all with a composite hash and a sealed timestamp.
Rate limits & errors
The API allows up to 100 requests per second per organization on paid plans. Free tier is limited to 10 requests per second. If you exceed the limit, you'll receive a 429 Too Many Requests response with a Retry-After header.
A 422 Unprocessable Entity means the request was syntactically valid but semantically wrong, for example, a missing required field in the payload, an invalid event type, or a URL that doesn't match your organization's domain.
See the Errors page in the developer docs. Every error response includes a machine-readable error code, a human-readable message, and (where applicable) a pointer to the offending field.