Invoance
Get a DemoLog InSign Up
Developers
Search docs…⌘K
Getting started
OverviewConceptsAuthenticationCreate an API key
API reference
EndpointsErrors
Audit Logs
Quick startIntegrationsEmbeddable viewerEvent schemaExporting eventsSDK reference
AI Attestations
Quick startAttestation schemaVerification & proofSDK reference
Events
OverviewSDK reference
Documents
OverviewSDK reference
Traces
OverviewSDK reference
SDKs
PythonNode.jsGoJavaRubyRust.NETPHPcURL
Verification
How it works
Support
API FAQ
Developers·Audit Logs·Integrations

Zero-code integrations

Point your auth provider's webhooks at Invoance and every organization in your app starts accumulating signed, independently verifiable audit events (sign-ins, membership changes, role updates) before your team writes a line of instrumentation. Clerk and Auth0 are supported today; each has its own setup guide and curated event map.

Providers

Clerk logoClerk

Svix-signed webhooks for organizations, memberships, roles, and sessions, with orgs auto-created under their real names.

Auth0 logoAuth0

Log-stream webhooks for sign-ins, signups, password and email changes. Deliveries arrive batched and are deduplicated by log id.

How it works

Create the endpoint

Dashboard → Audit Logs → Integrations → Connect provider. You get a unique webhook URL (shown once, stored hashed) plus provider-specific setup steps.

Every delivery is verified

Clerk deliveries carry a Svix signature; Auth0 sends the Authorization token you configured. Nothing is trusted before it verifies.

Events become signed records

Verified events are translated into a clean audit vocabulary, Ed25519-signed, and sealed into each organization's gap-free sequence, identical to events sent via the API.

Organizations appear on their own

Provider events carry the end-customer organization; unknown orgs are auto-created (up to your plan's limit) with their real names, each one a portal link away from being shown to your customer.

Delivery semantics

The receiver is built for at-least-once delivery: providers retry on failure, idempotency absorbs the retries, and permanent conditions are acknowledged with a 200 so a single odd event can never make your provider disable the endpoint. These rules are shared by every provider.

200 · receivedEvent mapped, signed, and sealed into the org's gap-free sequence. Clerk gets {received, event_id}; Auth0 batches get {received, accepted, skipped}.
200 · skippedPermanent, per-event condition: unmapped type, org-less event under the skip policy, org over your plan cap, or a paused source. Counted per source with a reason, visible in the dashboard's skip log. Never billed.
401Signature (Clerk) or Authorization token (Auth0) did not verify. Not counted as received.
404Unknown or deleted endpoint token.
429Per-source rate limit (with Retry-After), or your monthly signed-event allotment is exhausted; the provider's own retry becomes the backoff.
5xxTransient failure on our side. The provider retries; per-event idempotency keys (Svix message id / Auth0 log id) guarantee retries never create duplicates.

Quota: only events that are actually signed count against your allotment; skipped events are free, always. Org routing:each source either auto-creates organizations as their events arrive (up to your plan's org limit) or runs in allowlist mode, accepting only organizations you created yourself; org-less events are skipped or routed to a catch-all org you designate. Everything is switchable per source, live, from the dashboard.

Set it up under Dashboard → Audit Logs → Integrations. The receiver endpoint itself is documented in the API reference, and once events are flowing, the quick start shows how to instrument your product's own actions with one call each.

01Audit logs02AI decisions03Documents04Business events05Whole workflows
Invoance

Neutral proof infrastructure for records that must survive scrutiny. Signed at creation. Verifiable outside your dashboard.

ALL SYSTEMS OPERATIONALEvidence infrastructure · Online

Build

  • Developer overview
  • API endpoints
  • Official SDKs
  • Authentication
  • Verification model

Use Invoance

  • Why Invoance
  • How it works
  • Compliance teams
  • Finance teams
  • Pricing

Verify

  • Audit log
  • AI attestation
  • Document
  • Ledger event
  • Sealed trace

Company

  • Help center
  • Resources
  • Security
  • Partners
  • Contact
  • System status
FIELD NOTES / 01Proof patterns for teams building trust.

Invoance provides cryptographic proof and verification infrastructure. It does not provide legal, financial, compliance, or regulatory advice.

Read proof disclaimer

Records anchored with Invoance are cryptographically signed and designed to reveal tampering. Invoance verifies that a specific record existed in a particular form at a particular time; it does not assess the record's accuracy, authenticity, legality, or underlying contents. Public verification links can be resolved without authentication. Invoance is not a custodian of funds, a legal authority, or a regulated financial institution. Using Invoance does not by itself satisfy any legal or regulatory requirement. Consult qualified legal or compliance professionals regarding your obligations.

© 2025 – 2026 Invoance, Inc. All rights reserved.
PrivacyLegalFAQ
PROOF, NOT PROMISES.