Feature Availability

Feature availability and known limits

This page distinguishes the source implementation from assumptions a reader might make from interface text. It was reviewed on 3 October 2026. Operators should validate their deployed version before relying on an integration or advanced capability.

Capability	What the inspected code supports	Important limit
Agreement creation and editing	Upload, scratch drafting, fields, versions, clone, archive, and metadata routes	File type acceptance does not guarantee identical preview or sealing support
Review and signing	Designated review decisions, send, parallel/sequential routing, OTP, complete, decline, cancel, reminders	Email and expiry processing depend on deployment configuration
Templates	Create, revise, share, publish, instantiate	API share levels are USE/EDIT; some UI labels use different wording
Document REST API	CRUD under v1, v2, and unversioned document alias	v2 applies to document routes, not every API family
Document revision input	Schemas accept expectedRevision	Document PUT/PATCH handlers do not enforce it; do not rely on it as a concurrency lock
Document list sorting	Schemas accept sort and order	Handler uses creation time descending, then ID descending
Document PUT	Updates selected editable properties of a draft	It does not implement a general binary file replacement or clear all omitted properties
API client bindings	List, register, patch, revoke trusted bindings	No client-credentials token issuance endpoint or client secret rotation route is implemented here
API client UI	Creation and rotation controls are visible	Do not treat a control as proof the corresponding credential operation works
Webhook events	Registry, outbox publishing, subscription, filter, signing, delivery, retry, and replay services	Worker entry point does not wire a scheduled outbox dispatcher or retry processor
Webhook event catalog	Fifteen event names are registered	Registration alone does not prove every operation emits every event; test the actual producer path
Webhook rate setting	Subscription stores a per-minute value	Delivery code does not enforce a per-minute throttle; do not rely on it for traffic protection
Webhook metrics	Stored buckets, summary, CSV	period is returned but does not filter buckets in the current route
Automatic retries	Delivery service schedules retry timestamps	Scheduled retries require an operator-provided processor
PDF sealing	Routes invoke signing and timestamp services	Requires configured services and keys; completed status alone does not prove sealing succeeded
Public PDF browser check	Local SHA-256 computation, server hash lookup	This privacy behavior applies to that mode only
“Offline Verify”	Standalone endpoint and browser fallback	Browser and server contracts differ; the fallback is not a complete cryptographic validation. Do not rely on its displayed valid result as proof
Batch verification UI	File chooser and export controls	UI sends documents/results, but server requires items; the inspected contracts do not align
Conditional fields	Conditional rule schemas exist	End-to-end editor and signer behavior needs deployment validation
Interactive API docs	Scalar UI and OpenAPI endpoints	Current schemas are partial; some placeholders describe unimplemented operations

Before adopting an integration

1. Confirm the API base URL and version with your operator.
2. Obtain an approved token and the required scopes.
3. Test a harmless document through the exact creation and workflow path you intend to use.
4. Test a webhook and then a real domain event. Confirm dispatch and retry processing, rather than relying solely on a synthetic test.
5. Check the final file and verification outcome.
6. Record the tested deployment version and any operational dependencies.

These notes describe practical limits without publishing credentials or sensitive deployment configuration. Report reproducible issues with synthetic data through the project's issue tracker.