One of the most convenient features of eObig is sending a document to a counterparty for signature by link, without them having to create an account. They open the document, review it, and sign it with their own QES right in the browser. Below we go through how this works in the interface and via the API, and why it removes the main barrier to electronic document flow.
The problem: registration kills signing conversion
Most often, electronic exchange stalls not because of technology but because of a simple question from the counterparty: "Do I have to register in your service too?" For a one-off deal, a small client or an individual, this often means a refusal — the person isn't ready to set up an account, confirm an email, and figure out someone else's workspace just for a single signature.
The guest scenario removes this barrier entirely. You remain an eObig user, while your counterparty only needs a link. No accounts, no plugins — just the document and their usual signature.
How it works for the counterparty
From the recipient's side, everything looks as simple as possible. They receive a link (in an email, a messenger, or any convenient channel), open it in the browser, and see the document itself. Then they:
- Review the document — they see the final version you sent.
- Choose their QES medium — a file key, Diia.Signature, SmartID, and so on.
- Sign right in the browser — with no software or extensions to install.
- Receive a signed copy — the document comes back signed by both sides.
Importantly, the counterparty's private key generates the signature locally, on their device, and is never transmitted anywhere. For more on this mechanism, see the article on browser-based signing security.
Step by step in the interface
On your side, as the sender, the scenario also takes just a few minutes:
- Open the document in your account or upload a new file.
- Choose to send for signature by link — this is the guest mode that requires no account from the recipient.
- Specify the counterparty and send them the link through any convenient channel.
- Wait for the signature — as soon as the counterparty signs, you'll see the status and receive the signed version.
A copy of the signed document stays with both parties. For you it's a familiar workflow; for the counterparty it's one click on a link. For the full cycle of working with counterparties, read the article on exchanging documents with counterparties online.
Via the API: guest links
The same scenario is available programmatically — handy when you need to embed the counterparty's signature into your own product, CRM, or client's personal cabinet.
The logic is simple: you create a guest link to a specific document in "sign" or "fill" mode. In response you get a URL of the form /external/<token>, which you pass to the counterparty. The key properties of such a link are:
| Property | What it means |
|---|---|
| Mode | "sign" or "fill" — depending on the scenario |
| URL format | /external/<token> — a unique link to the document |
| Time to live (TTL) | The link is valid for a limited time and later becomes invalid |
| Webhook event | After signing, you receive a notification |
| Result | The signed version of the document is returned to your system |
In other words, the counterparty installs nothing and registers nowhere, while your application learns about the signature automatically via a webhook and immediately receives the signed file. For how to embed this into your own processes, see the detailed article on integrating eObig into your CRM.
As for access: self-service issuance of API keys in the cabinet isn't available yet — we grant access to the partner API on request. Just reach out to the team or request a demo, and we'll help you wire up the scenario. At the same time, signing by link without registration already works in the product today — the API is only needed when you want to automate it within your own interface.
Legal force and security
Guest signing is in no way inferior to the standard one. The counterparty applies a qualified electronic signature (QES), and a document signed with QES has the same legal force as a paper one signed by hand. It is accepted by courts, regulators, and other counterparties.
Security rests on the same principle as the standard scenario: the private key never leaves the counterparty's device, the signature is generated locally in the browser, and the link's lifetime is limited. For more on the mechanism, see the articles on how to sign a document online without plugins and the overview of platform features.
When it is especially useful
Guest signing by link shines brightest where the counterparty isn't a permanent partner:
- One-off deals — when there's no point in setting up an account for a single document.
- Individual clients — people sign with their own QES without extra registrations.
- Legal documents — contracts, acts, consents, where the legal force of QES matters.
- External signers in your products — when the signature needs to be embedded into the customer journey via the API.
Key takeaways
- The counterparty signs the document by link, without registering in the service and without plugins.
- The signature is qualified (QES), generated locally; the private key never leaves the counterparty's device.
- Via the API you create a guest link
/external/<token>with a limited lifetime, and after signing you receive a webhook and the signed version. - The legal force is the same as with standard QES signing; a copy stays with both parties.
- The scenario is available in the product today; access to the partner API is by request.
Start free at portal.eobig.com or request a demo — and we'll show you how to send your first document for signature so that your counterparty doesn't have to register.