Invoance solves the lack of verifiable proof in modern business and software workflows by recording cryptographic evidence of what happened, when it happened, and who issued it, without relying on visual trust, inbox context, or internal system authority.

Invoance is a single proof API with five products: Audit Logs (signed, customer-facing activity logs you can embed, stream, and export), the Event Ledger (an append-only record of business and system events), AI Attestation (tamper-evident proof of AI inputs and outputs), Document Anchoring (proof that a document existed unchanged at a point in time), and Traces (grouping related events into one sealed, verifiable process proof). Every product shares the same Ed25519 signing and the same independent verification.

Application and business activity such as user actions, approvals, access events, API calls, invoice issuance, AI inferences, and the documents attached to them. Documents are treated as one type of event payload, not the source of trust.

Yes. Invoance can record internal events such as approvals, system actions, and workflow milestones, creating verifiable proof even within a single organization.

No. Invoance operates alongside existing tools by independently recording proof of events, without changing how emails, approvals, or systems function.

Audit Logs is an API for recording your application's activity as signed, independently verifiable events and exposing them to your own customers. Every event is Ed25519-signed at the source, so anyone can confirm it was not altered after the fact. It is the audit-log layer B2B SaaS teams are asked to build for enterprise deals, without building it yourself.

Conventional logs and most audit-log APIs ask you to trust the provider's database. Invoance signs every event with your tenant's Ed25519 key at ingestion, so the record carries its own proof. A customer, an auditor, or you can verify any event independently with no trust in Invoance required. Verifiability is the differentiator.

Each event records an action, the time it occurred, the actor who performed it, the targets it affected, and optional structured metadata. Events are scoped to one of your end-customer organizations and assigned a gap-free per-organization sequence number, so missing or reordered events are detectable.

Yes. Invoance includes a hosted, embeddable viewer you open for a specific customer organization through a short-lived, single-use link. It is read-only, scoped to that one organization, and carries your branding. The end customer needs no Invoance account or login.

Yes. You can configure outbound webhook streams that deliver events in order to a customer's SIEM or endpoint. Deliveries are HMAC-signed, retried with backoff on failure, and protected by SSRF controls. The generic signed webhook works today; a dedicated Splunk HEC connector is on the roadmap.

Yes. Exports run asynchronously and return a presigned download covering both recent (hot) and archived (cold) events for the filters you choose, in CSV or JSON. CSV output is hardened against spreadsheet formula injection.

Every event includes the signed canonical payload, the signing public key, and the Ed25519 signature. The Python and Node.js SDKs verify signatures client-side with no network call to Invoance. You can also fetch the raw canonical bytes via API and recompute the SHA-256 hash yourself.

Retention is plan-driven. Recent events stay in fast hot storage; older events are archived to encrypted cold object storage and stay exportable until they pass your plan's retention window. Events are append-only: they cannot be edited, and removal happens only through the logged retention process.

The Invoance Event Ledger is an append-only, compliance-grade system of record that captures verifiable business and user activity as signed, append-only events. It is designed for audits, disputes, investigations, and regulatory review, not analytics or logging.

Logs and analytics are mutable, operational tools optimized for debugging and insights. The Event Ledger is append-only, deterministic, and auditable, designed to serve as an authoritative record when trust in primary systems is questioned.

They run on the same signing and verification engine. The Event Ledger is your own internal system of record for business and system events. Audit Logs is the customer-facing product: the same kind of signed events, but scoped per end-customer organization and exposed to your customers through an embeddable viewer, SIEM streams, and exports.

Any business or system activity such as user actions, approvals, access events, workflow milestones, API calls, policy enforcement actions, and document-related events. Documents are treated as one event type, not a special case.

No. Events are append-only. Once ingested, they cannot be modified or deleted outside of policy-driven, logged retention expiry. Manual edits or removals are not possible.

Each event is cryptographically hashed and Ed25519-signed, and grouped into Merkle roots, making tampering detectable and independently provable.

Both client-claimed event time (optional) and server-authoritative ingestion time (mandatory) are stored permanently. Neither timestamp is normalized or overwritten.

Yes. Each tenant has isolated event chains, retention policies, and access controls. Cross-tenant visibility is not possible.

Yes. Events can be exported as ordered, verifiable packages that include hashes, timestamps, and proof data. Exports can be verified offline without access to Invoance systems.

An AI attestation is a cryptographically signed record that binds an AI model's input and output to a specific model provider, model name, version, and timestamp. It proves what an AI system produced, when, and under what configuration, without relying on the AI provider's logs.

Invoance is model-agnostic. You provide the model provider name, model name, and version as metadata when creating an attestation. Any AI system that produces text input/output pairs can be attested: OpenAI, Anthropic, Google, open-source models, or your own.

The input text, output text, model metadata (provider, name, version), attestation type, and optional subject identifiers are canonicalized into a deterministic JSON payload. This payload is SHA-256 hashed and Ed25519 signed. Individual input and output hashes are also stored separately for granular verification.

Yes. Every AI attestation has a public verification link at invoance.com/proof/ai/{attestation_id} that anyone can use without authentication. The raw canonical payload can also be retrieved via API for independent hash recomputation.

The EU AI Act requires demonstrable records of AI system behavior for high-risk applications. AI attestations create a signed, append-only audit trail of what the AI produced, preserving evidence independently of the AI provider. The Growth, Compliance, and Enterprise tiers include dedicated EU AI Act audit trail support.

The API accepts input and output as text strings. Practical limits are enforced by payload size constraints. For very large outputs, consider hashing the content client-side and storing the full text in your own systems while anchoring the hash through Invoance.

Document anchoring records a cryptographic hash of a document, bound to a timestamp and your organization's identity, producing proof the exact document existed at that moment. The proof holds even if the file is later changed, because any change produces a different hash.

No. By default Invoance stores only the hash, timestamp, and minimal metadata, never the file contents. Storing the original bytes is optional and billed separately. Verification never requires the stored file.

Recompute the document's SHA-256 hash and compare it to the anchored hash, either through the public verification page or client-side with the SDK. A match proves the document is byte-for-byte the one that was anchored; a mismatch flags any alteration.

Both run on the same signing and verification engine. A document anchor is one event type focused on a single file's integrity, while the Event Ledger records broader business and system activity. Many teams use both.

A Trace groups related events and documents into a single sealed bundle with one composite hash, so you can prove an entire business process happened as recorded, not just individual steps. An approval that spans a request, a review, and a sign-off can be captured as one verifiable unit.

Sealing computes a composite hash over the bundle's members and signs it. After that, the set of events in the Trace and their contents are fixed: adding, removing, or altering any member breaks verification.

Anyone can verify a sealed Trace through its public verification page or with the SDK. Verification confirms every member event is authentic and that the bundle has not changed since it was sealed.

No. Traces are included on every plan with a monthly allotment and no overage charges. See Pricing for the amount included on each tier.

Invoance provides a neutral, append-only proof layer that can support audits and investigations, but it does not replace regulatory, legal, or compliance controls.

Ownership remains with the issuing and receiving parties. Invoance does not claim authority over records and acts only as an independent verification layer.

Not by default. Invoance records cryptographic hashes, timestamps, and minimal event metadata. Storing original documents or payloads is optional and never required for verification.

Cryptographic hashes in the append-only ledger are irreversible and cannot be altered or deleted, this is by design to preserve proof integrity. Optional stored payloads and original documents can be deleted on request. If you need full tenant data removal, you can request complete account deletion.

Invoance is built to support organizations operating under these frameworks. The Growth and Compliance tiers include 7-year retention for SOX Section 404, EU AI Act audit trails, and compliance event ledger access. Enterprise plans include BAA availability for HIPAA-covered entities and audit-ready compliance reports.

Invoance records are cryptographically signed, timestamped, and independently verifiable. While they can support legal proceedings as technical evidence, Invoance does not guarantee legal admissibility, that depends on jurisdiction and context. Consult qualified counsel for your specific obligations.

No. Invoance operates as a high-performance event ledger. External blockchain anchoring is optional and used only as an additional verification layer.

It confirms that a recorded event or document payload matches the cryptographic proof created at the time of issuance and has not been altered.

A failure indicates the event or payload does not match the original proof, signaling possible alteration, impersonation, or unauthorized action.

Yes. Invoance is API-first and designed to record events directly from systems, services, and automated workflows.

SHA-256 for content hashing and Ed25519 for digital signatures. Payloads are deterministically canonicalized (recursive key sorting) before hashing to ensure the same content always produces the same hash. All data is encrypted in transit (TLS 1.3) and at rest.

Yes. The SDKs include client-side Ed25519 signature verification. Given the signed payload, public key, and signature, all returned in the attestation or event record, you can independently verify integrity without any network call to Invoance.

Rate limits are enforced per API key and vary by plan. All tiers include generous quotas for events, audit logs, documents, attestations, and verifications. Enterprise plans include priority rate limits. Exceeding limits returns HTTP 429 with retry-after headers.

Yes. There are eight official SDKs: Node, Python, Go, Java, Ruby, Rust, .NET and PHP. Each covers every API endpoint, including the audit namespace, with typed responses. Node and Python also verify hashes and Ed25519 signatures client-side and read the API key from the environment. Install commands are on the developer FAQ.

Invoance enforces tenant isolation at the database level with row-level security. API credentials are scoped per organization. Data is never shared with third parties, used for advertising, or fed into AI training pipelines.

Each tenant has a unique Ed25519 keypair. Signatures are generated at ingestion time and stored append-only. Even if infrastructure were compromised, previously signed records remain independently verifiable using the public key. Forging a valid signature requires the private key, which is never exposed via API.

No. Server-authoritative ingestion timestamps are recorded at write time and cannot be overwritten. An optional client-claimed event time can be provided for your own records, but it is stored separately and never treated as the authoritative timestamp.

No. UPDATE and DELETE operations are structurally revoked at the database level for ledger tables. Records are append-only by design, not by policy but by architecture. This applies to Invoance engineers as well.

Invoance collects only the data necessary to operate the service: account information, API request metadata, and whatever payload content you choose to anchor. No behavioral profiling, advertising trackers, or unnecessary personal data collection. See our Privacy Notice for full details.

API keys are hashed before storage, plaintext is never persisted. Keys are scoped to a single organization with assigned read or write permissions, including separate audit read and write scopes. You can revoke keys instantly from your dashboard, and revoked keys are rejected on the next request with no cache delay.

Every record captures a snapshot of your organization's issuer name at the exact moment of ingestion. Proof pages always display the issuer name as it was when the event, document, or attestation was anchored, not the current name. This preserves audit-grade accuracy: if your company was 'Acme Corp' when an invoice was recorded, the proof page will always say 'Acme Corp', even if you later rename to 'Acme Holdings'. Records created before this feature was introduced will fall back to the current organization name.

Yes. Individuals can verify business events, documents, or requests through the web without creating an account, depending on issuer configuration.

No. Verification is public by design and does not require trust in Invoance or account ownership.

Invoance does not judge intent, legality, or correctness. It verifies whether an event or record is authentic and unchanged since issuance.

Yes. The Developer tier is free with no credit card and includes, per month, 1,000 ledger events, 10,000 audit log events, 50 documents, 50 AI attestations, 250 traces, and 500 API verifications, with 30-day retention.

Audit log events are bundled into every plan: 10,000 per month on Developer, 1,000,000 on Builder, 5,000,000 on Growth, 25,000,000 on Compliance, and unlimited on Enterprise. If you need more mid-cycle, you can top up an extra 1,000,000 events for $99, applied to the current billing period. Public verification of audit events is always free.

Yes. Traces are included on every plan with a monthly allotment (250 on Developer up to 1,250,000 on Compliance, custom on Enterprise) and no overage charges.

On the Developer tier, write operations (events, audit events, documents, attestations) are rejected with HTTP 429 once a quota is reached. On Builder, Growth, and Compliance tiers you can continue at published overage rates or add a top-up instantly, so nothing is silently dropped. Reads and public verification always keep working, and you are notified at 80% of any quota.

Developer retains records for 30 days, Builder for 1 year, Growth and Compliance for 7 years (meeting SOX Section 404 requirements), and Enterprise offers custom retention with legal hold capability. Retention is enforced at ingestion; upgrading your plan does not retroactively extend already-expired records.

Hash anchoring is always included in your plan quota. Storing original document bytes is optional and costs $0.025/GB/month on paid tiers. The Developer tier includes 0.1 GB, Builder includes 2 GB, Growth includes 10 GB, and Compliance includes 100 GB.

Yes. Public verification via web links is always free for anyone, with no account, no API key, and no quota deduction. API-based verification (programmatic calls) counts against your plan's verification quota.

Yes. Annual billing offers a discount (roughly 20% savings). You can switch between billing cycles from your dashboard. Enterprise plans use custom invoicing.