Short answer: Aamu.app lets teams send a Doc to one or more signers and track the request from the document. Teams can use Aamu email OTP without Signicat or connect their own Signicat account for Finnish strong authentication.
Agreements often begin as working documents. A proposal is drafted, reviewed, commented on, and revised before anyone needs to sign it. Aamu.app now lets a team continue that workflow from an Aamu Doc into a signature request without moving the final document and its context into a separate signing system.
A signature request can include one or more signers. The sender chooses an available signing method for each person, sends the request, and follows its progress from the Doc. Aamu currently supports its own email one-time-code method and Finnish strong authentication through a team's Signicat connection.
Start from an Aamu Doc
Open the signature dialog from the Doc that contains the agreement. Add each signer's name and email address, select a signing method, and set the request's due date. If the Doc is not yet accessible through a suitable share link, the dialog provides a direct path to the Doc sharing controls first.
Sending creates one signature request for the document and an individual signing session for every signer. The request stays connected to the original Doc, so the team can return to the same place to see whether people are waiting, have signed, or whether the request is only partially complete.
Email OTP works without Signicat
Email OTP is Aamu's built-in signing method. It does not require the team to create a Signicat account or configure another identity provider. This makes it a practical default for signers in different countries when confirming control of an email address is an appropriate level of assurance for the agreement.
The signer opens a personal signing link, reviews the document, requests a one-time code, and receives that code by email. The Sign button remains unavailable until a code has been entered. Aamu verifies the code before accepting the signature and reports an incorrect or expired code clearly instead of treating the attempt as a completed signature.
Email OTP proves access to the recipient's email account at signing time. It is not the same as government-backed or bank-backed strong electronic identification. Teams should choose the signing method based on the agreement, the parties, and the legal or compliance requirements that apply to them.
Finnish strong authentication through Signicat
For agreements that need stronger identity assurance in Finland, a team can connect its own Signicat account and offer Finnish Trust Network authentication. The signer completes the identity flow using a method made available by the team's Signicat configuration, such as online banking credentials or a mobile certificate.
The Signicat agreement belongs to the Aamu team, not to Aamu globally. An administrator adds or replaces the connection under Team settings, where Aamu also shows the webhook URL needed for automatic status updates. This team-scoped provider model keeps credentials and commercial identity-provider relationships under the team's control.
Signicat must have suitable identity-provider methods enabled for the account. A successful API connection by itself does not make an authentication method available; the account configuration determines which methods a signer can actually use.
Automatic status updates
Aamu receives Signicat webhook events and uses them to update the signature request automatically. A manual status check remains useful as a fallback, but the normal workflow does not require someone to keep pressing a refresh or check button after every signature.
The signature dialog subscribes to a limited live projection of the request data. Status changes can therefore appear in the Doc as they are recorded, while server-only details such as authentication secrets and provider internals are not exposed to the browser.
Track each signer from the document
The request summary distinguishes waiting, partially signed, signed, expired, cancelled, and failed states. Each signer has an individual method and status, including the signing time after completion. Colour-coded status labels make completed and partially completed requests easier to scan.
The sender can resend an invitation when a signer needs another email, or cancel an outstanding request when the agreement should no longer be signed. Due dates and a background expiry process prevent old requests from remaining open indefinitely.
Evidence belongs with the signature
A completed email OTP signature produces human-readable evidence together with machine-readable audit data. The evidence records the document identity and content hash, the signer, relevant timestamps, the method used, and verification information. Provider-backed signatures retain the corresponding provider result and status information.
The content hash is important: it connects the evidence to the exact document content presented for signing. Audit evidence supports later verification, but it does not by itself decide whether a signature satisfies every law, contract policy, or regulated process. That assessment depends on the selected method and the context in which it is used.
One workflow, several signing providers
Email OTP and Signicat use the same Aamu workflow even though they provide different levels and kinds of assurance. The Doc, signer list, invitations, request tracking, cancellation, expiry, and evidence handling remain consistent; the provider handles the method-specific signing step.
This provider model also gives Aamu a path beyond one country or identity network. A team can use the globally accessible email method where it fits and connect stronger regional or industry-specific providers when an agreement requires them.
Choosing a method
Use Email OTP when a simple remote acknowledgement tied to an email address is sufficient and signers should not need a country-specific identity method.
Use Finnish strong authentication when the workflow needs stronger identity assurance and the team's Signicat agreement has the required Finnish methods enabled.
Confirm legal, regulatory, and retention requirements separately when the agreement is high-value, regulated, or must meet a particular electronic-signature classification.
The practical result is that the signing step can stay next to the document and the team that prepared it. Aamu handles the shared workflow, while each team decides which identity provider and assurance level its agreements require.
Frequently asked questions
Does Aamu email OTP require Signicat?
No. Email OTP is built into Aamu and works without a Signicat account or another external identity provider.
What does email OTP verify?
Email OTP verifies that the signer can receive and enter a one-time code sent to the specified email address. It is not equivalent to government-backed or bank-backed strong identification.
How does Aamu support Finnish strong authentication?
Each Aamu team can connect its own Signicat account and use the Finnish identity methods enabled for that account, including supported bank or mobile identity methods.
Can a signature request have several signers?
Yes. A request can include multiple signers, and Aamu tracks the method and status of each signer separately.
Does Aamu update Signicat signature status automatically?
Yes. A configured Signicat webhook updates the request automatically, while a manual status check remains available as a fallback.