Security and Audit Trail

Security and audit trail

Use the platform's access controls and audit records together with your organization's document handling and retention policies.

What the application records

Audit and document history can record who acted, what action occurred, when it occurred, and associated request context. The audit implementation includes hash-linked records intended to make changes evident. Such records support investigation; they are not a blanket guarantee that an entire deployment is immutable or independently certified.

To review activity, open an agreement's history or the authorized audit view. Check the event time, actor, document state, and relevant details. Use notification history to inspect recorded email activity. Retain the completed document and supporting evidence through an approved process.

Access boundaries

Agreement, template, and organization operations use workspace context and relevant permission checks. Integrations additionally require API scopes. Different route families use different authorization middleware; do not assume a single role grants identical access everywhere.

Platform administration and workspace document access are separate. The agreement file route restricts the platform super-administrator role to metadata. Administrators should use approved organizational access rather than assuming service administration authorizes private document reading.

Handle links, credentials, and evidence safely

• Keep signing invitations, reset links, session tokens, and one-time codes private.
• Never publish passwords, MFA QR codes, private keys, certificate key bundles, webhook secrets, or authorization headers.
• Use synthetic documents and fictional contact details for demos and documentation.
• Before sharing a screenshot, inspect names, addresses, document content, URLs, QR codes, and notification text.
• Review logs before sharing them. Redaction is useful but does not guarantee every user-supplied value is safe.
• Store completed files and exported audit evidence in an approved location with appropriate access.

API request logs

Authorized users can open Integrations & Developer APIs → API Request Logs. The API supports filtering by request ID, method, route, status code, and time range. A request ID helps the operator investigate an error without publishing an entire request.

Request logs and agreement audit history serve different purposes. Request logs describe API traffic; audit records describe document and administrative actions. Both may contain sensitive context and should be shared only through an approved private support channel.

Document authenticity and trust

Use Cryptographic Signing and Verification to check the actual final file. Cryptographic integrity, certificate trust, signer intent, and legal suitability are distinct questions. This wiki does not certify compliance with a legal or regulatory framework.

Documentation publication policy

These pages deliberately use generic API origins and environment placeholders. They contain no actual access tokens, passwords, signing invitations, private keys, infrastructure account identifiers, or customer document content. Screenshots show empty public screens; credential-setup screens and customer account views are excluded. Public documentation should explain supported usage without exposing operational secrets, internal incident reports, or bypass instructions.