One-Shot is delivered with One-Shot Optimizer, a server that exposes the One-Shot HTTP RESTful API. Business applications call this API to process electronic signature requests based on single-use certificates.
One-Shot Optimizer performs the most computationally expensive part of the signature process. This reduces data traffic on the local network and uses cryptographic hardware acceleration when available. Documents to be signed are processed in the customer business layer; only a hash of each document is sent to Uanataca services. The original document is never transmitted.
Uanataca acts as a Qualified Trusted Service Provider and issues digital certificates through its own Certification Authority (CA). Registration Authority Officials (RAO) manage requests for new certificates. With One-Shot Signature, you assume the RAO role: you provide identification data for each user and request the generation of signature certificates. The end user then triggers the issuance (e.g. by entering an OTP), and the single-use certificate is created and used immediately to sign the documents.
Signatures are performed on the Uanataca Trusted Service Center side, where signature keys are generated and stored in a QSCD (Qualified Electronic Signature Creation Device).
Business application Your system that creates signature requests, uploads documents or hash payloads, retrieves the service contract, triggers OTP or other authentication, and calls the sign and document retrieval endpoints.
One-Shot Optimizer The runtime that exposes the One-Shot REST API. It computes hashes of documents in the business layer, sends hashes to Uanataca, receives signed hashes, and builds the signed document envelope (or returns signed P7M in hash-signature flow). When deployed with Docker Compose, it runs alongside a Redis container and uses Redis to cache heavy, non-sensitive data to improve flow efficiency (no sensitive information, document data, or the document itself is stored in Redis); if Redis is unavailable, it falls back to local storage.
Redis Started together with the Optimizer when you deploy via Docker Compose. The Optimizer connects to it on the same network (hostname
redis, default port) to store and retrieve non-sensitive, heavy data and improve performance. Redis does not hold sensitive information, document content, or the document itself—only operational cache data. Redis runs as a basic instance with no special configuration. Changing the Redis connection (host or port) is done via the Optimizer configuration (see Service settings).Uanataca Trusted Service Center Where single-use certificates are issued and used. Keys are generated and stored in the QSCD; hashes are signed and returned to the Optimizer.
Documents are processed in your environment. Only a cryptographic hash of each document is sent to the signature service (in the classic and async flows, the Optimizer can compute the hash from the uploaded file). The original document never leaves your premises. This model ensures document content remains under your control and reduces data transfer.
One-Shot Signature certificates are generated on the spot for each new set of documents. After the end user completes authentication (OTP or other approved method), the certificate is issued and used immediately to sign the requested documents, then the procedure is complete.
- Signing flow — High-level steps and workflow types
- Workflows overview — Classic, hash, async, VideoID
- Webhooks — Status change callbacks