How Audit Logs are signed at the source
Audit Logs accept any customer activity event, sign it with your organization's Ed25519 key the instant it lands, and store it in an append-only log your customers can view, stream, export, and verify themselves. From a single API call to proof an auditor will accept.
What you send
Every event is a strongly-typed JSON envelope: which organization it belongs to, the action that occurred, the actor who triggered it, the targets it touched, and typed metadata. An Idempotency-Key header makes the write safe to retry.
Idempotency-Key: 7f4c1c9d-5b8a-4d42-9e0b-1f2a3b4c5d6e
{
"organization_id": "org_01J8F3KQ2R7VWX9YB4ND6MCZAH",
"action": "user.signed_in",
"actor": { "type": "user", "id": "user_123", "name": "Jordan Reyes" },
"targets": [{ "type": "team", "id": "team_42" }],
"metadata": { "ip": "203.0.113.7" },
"occurred_at": "2026-06-24T16:44:08Z"
}The audit org, your end customer, the event belongs to. Register each one once via POST /v1/audit/orgs; every event references it.
A dot-segmented string like user.signed_in or billing.invoice.paid. The grammar keeps actions consistent and the log cleanly filterable.
Who performed the action, structured by type, a user, a service account, or the system itself, and id. The name is optional, the id is not.
The objects an action touched, each by type and id, so the log filters cleanly by what actually changed.
Typed scalars, strings, integers, booleans, attached to the event, the actor, or any target. Nesting and floats are rejected by design.
When the action actually happened. Optional, the SDKs default it to now and validate it to a sane window so the timeline stays trustworthy.
Required on every write. A retried request resolves to the same record instead of doubling it. The SDKs generate the key for you.
What happens on ingestion
When Invoance receives an event, a deterministic 5-step flow runs. Bad shapes are rejected before anything is written; valid events are signed and appended.
The event is checked against a strongly-typed schema, the action grammar, structured actor and targets, scalar-only metadata. Unknown fields, nesting, and floats are rejected at the door, so a bad shape never reaches the log.
The Idempotency-Key is matched against recent writes. A redelivered or retried request resolves to the existing record instead of creating a duplicate, making ingestion safe for at-least-once pipelines.
A SHA-256 hash is computed over the canonical bytes of the event. Alter a single character of any field and the hash, and the signature that depends on it, no longer match.
The hash is signed with the Ed25519 key bound to your organization, and the event is assigned a per-org sequence number plus an ingestion timestamp. The signature proves origin; the sequence gives the log a stable total order.
The complete record (envelope, hash, signature, sequence, timestamps) is written to append-only storage. Records are added, never rewritten, and paginate in stable order.
What you receive
Ingestion returns a compact acknowledgement: the event id and its effective timestamp. Use the id to retrieve, list, or verify the record at any time.
{
"event_id": "9549c332-a52b-4d1e-8c7a-2f1b9e3d4c5a",
"occurred_at": "2026-06-24T16:44:08Z"
}Unique identifier for the event. Use it to retrieve, verify, or reference the record later.
The effective time of the event, echoed back, either the value you sent or the default the SDK applied.
The customer portal
Enterprise buyers ask for their audit trail. Instead of building a viewer, mint a single-use private link. It opens a hosted, branded portal scoped to one organization, where your customer searches, verifies, exports, and wires up their own streams. Session length is yours to set.
Filter by actor, action, target, and time window over a fast, keyset-paginated view of the org's log.
One click checks the Ed25519 signature for a record and shows the verdict, right inside the portal.
Your customer pulls their own range to CSV, JSON, or PDF without filing a ticket with your team.
Customers add their own webhook destinations, watch delivery health, and send a test, all without your involvement.
Stream and export
Some customers want the log pushed to them in real time. Others want a file for their own warehouse. You get both without building delivery infrastructure.
Point a stream at any HTTPS endpoint, including a SIEM or log pipeline. Every delivery is HMAC-signed so the receiver can verify it, destinations are checked against an SSRF guard, and delivery is at-least-once from a durable cursor. Send a test before you go live.
Request a range as CSV or NDJSON and get back a presigned download. The serializer is injection-safe, so a malicious cell value can never turn an export into a spreadsheet formula. One call, one file, ready for an auditor.
How verification works
Verification is deterministic and requires no trust in Invoance. Anyone with the event and your organization's public key can confirm the record is authentic and unchanged.
Fetch the event via the API or the portal. You get the full signed envelope, the SHA-256 hash, the per-org sequence, and the Ed25519 signature.
The SDK rebuilds the exact canonical bytes that were signed from the event fields, the same input the signer used at ingestion.
Check the signature against your organization's public key. A valid signature proves the event came from you and has not changed since it was signed.
None of this requires a network call to Invoance. The SDK's client.audit.events.verify runs the check locally against the public key.
{
"valid": true,
"signed_by": "org_01J8F3KQ2R7VWX9YB4ND6MCZAH",
"verified_at": "2026-06-24T16:45:01Z"
}Technical guarantees
These are structural properties of Audit Logs, enforced by cryptography and database design. They hold for every organization and every event, regardless of plan or volume.
Every event is Ed25519-signed the instant it lands, with a key bound to your organization. The signature travels with the record, so authenticity is built in, not bolted on.
Any change to any field, no matter how small, produces a completely different SHA-256 hash, instantly invalidating the signature.
Records are added, never updated in place. The write path inserts; it does not rewrite history.
Each event receives a per-organization sequence number, giving the log a stable total order you can page through and reconcile.
A required Idempotency-Key means a retried write never doubles a record, even from at-least-once pipelines.
Any party can verify an event offline with only your public key and the Ed25519 signature. No Invoance server, no network call.
Compliance mapping
Audit Logs' technical controls align with the activity-logging and integrity requirements of major frameworks. Your auditor maps these controls to your specific compliance scope.
Logical access and activity logging, security event monitoring, and evaluation of events through a signed, tamper-evident trail.
Audit controls that record and examine activity in systems handling ePHI, plus integrity controls proving records have not been altered.
Logging of user activities and monitoring, with records protected against tampering and verifiable after the fact.
Integrity and confidentiality of processing, records of processing activities, and the evidence needed to support breach-notification timelines.
Invoance provides the technical control. Your auditor or compliance officer maps it to your specific audit scope and regulatory context.
Give your customers a verifiable audit log
Start with one event. The same cryptographic guarantees apply whether you are logging a handful of actions or millions, across every customer you serve.
How Audit Logs Work, Invoance
Technical walkthrough of how Invoance Audit Logs ingest customer activity events into a strongly-typed envelope, hash them with SHA-256, sign them with a per-organization Ed25519 key at ingestion, assign a per-org sequence, and write them to append-only storage. Every event is signed at the source, streamable to a SIEM, exportable for an auditor, and independently verifiable offline against your public key with no Invoance account required.