Security & Compliance

Every signature record's date field is assigned by the API at the moment a signature is received — never read from the client. A signer's device clock, time zone, or a tampered request body has no way to influence it.

This matters specifically for backdating: without a server-assigned timestamp, anyone with API access to the client key could submit a signature claiming it happened earlier than it did.

Location is null by default. It's only populated if the signer is shown a consent prompt and explicitly agrees — the widget never requests location silently in the background.

If consent is declined, the signature is still captured and submitted normally; location is simply omitted rather than the capture being blocked.

Each project has a public key (safe to embed client-side, scopes submissions to that project) and a secret key (server-side only, used to read signature records back). They're separate on purpose: a leaked public key lets someone submit signatures into your project, not read existing ones.

Rotating a key invalidates the old one immediately — there's no overlap window where both the old and new key work, so a rotation in response to a suspected leak takes effect right away.

Signature records persist until explicitly deleted. Deletion is available per-record through the API for cases where a right-to-erasure request applies.

SignFlow doesn't impose a retention limit itself — how long you keep records, and under what policy, is a decision for your own data-retention policy to make, not something the package enforces for you.

Dashboard accounts sign in through GitHub or Google OAuth only — there's no separate password to leak, phish, or reuse across services. Access to a project's keys is scoped to the account that created it.

What this page describes is what happens at the protocol level. Pair it with your own review of which evidentiary standard your use case actually needs to meet.