Signaturit in Odoo: What a Native Module Gives You That Zapier Doesn't

Short answer: Zapier is fine for firing off a signature request and finding out it was completed. It is not fine for reflecting inside Odoo the intermediate states a document goes through, nor for recovering from a lost webhook, nor for filing the signed PDF and its audit trail on the right record. If your process ends when the customer signs, a Zap is enough and it is cheaper. If your process starts when the customer signs — invoice it, open the file, onboard the employee — you need those states inside the ERP.

The starting point: the document travels by email

The usual loop has three manual hops: someone renders the quotation PDF in Odoo, uploads it to the Signaturit dashboard and waits; when the customer signs, the signed PDF lands in one person's inbox; that person re-uploads it to Odoo, if they remember. The symptoms are always the same: nobody knows whether the customer opened it, the signed PDF ends up on somebody's desktop, and when the evidence is needed — the audit trail — it isn't next to the invoice, which is where anyone would look.

One prerequisite first, and it hits all three routes equally: your Signaturit plan has to include API access. Authentication is a Bearer token you take from the dashboard, and sandbox and production are two separate registrations with two separate tokens. Signaturit does not publish which plans include that access, so confirm it with them before you design anything. No token, no Zap, no n8n, no module.

The three ways to connect them, and where Zapier is enough

As of today, Signaturit's Zapier app publishes exactly one trigger — “New Signed Document” — and five actions: create a signature request, create one from a template, cancel it, send a reminder, and create a certified email. The self-hosted Odoo app, on its side, exposes generic record-level triggers and actions (create a record, a lead, a task…). That is the whole raw material available.

Where Zapier is enough (and you can stop reading)

If you send one type of document, a handful a month, and all you need is a task or a chat message when it gets signed, build a Zap and stop worrying. It is also enough when the document doesn't originate in Odoo — an NDA prepared straight in the Signaturit dashboard. The rule: if the signature state doesn't change a decision inside the ERP, the ERP doesn't need to know it.

Which document comes out of which Odoo model

This is the part a generic “create a record” step cannot do: it has no idea how to render the QWeb report of a sales order. Every model needs three things of its own: the title the signer will see, the default recipient, and how the PDF is produced. In the connector we built, each bridge answers exactly those three questions.

• Quotation and sales order (sale.order): the standard sales-order report, with the customer as signer.
• Invoice (account.move) and purchase order (purchase.order), for acceptances and supplier confirmations.
• Delivery note (stock.picking): the delivery report, which once signed works as proof of delivery.
• Employment contract: hr.contract on Odoo 17 and 18, and hr.version on Odoo 19, where the HR module was reworked — the kind of detail that forces three code branches instead of one.
• Job offer (hr.applicant), CRM opportunity (crm.lead), ticket (helpdesk.ticket) and project and task, for work-acceptance sign-offs.

The full state cycle, which is where everything else breaks

The Signaturit v3 API reports eight per-document statuses: in_queue, ready, signing, completed, expired, canceled, declined and error. Its webhook events are finer still: email delivered, email bounced, document opened, document signed, photo ID added, expiration extended, audit trail completed…

Inside Odoo that has to become two different things. First: the request itself, with its own cycle — draft, sent, in progress, completed, declined, expired, canceled, error. Second: a field on the source document, so the salesperson opening the quotation sees the state without leaving the quotation. In our connector that field has seven values: not sent, awaiting signature, signed, declined, expired, canceled and error.

With several signers, the state has to be derived from the set: all completed, completed; one declines, declined; some signed and some not, in progress. And there is a guard you only learn by failing: a manually cancelled request must never be overwritten by a later event, because Signaturit can report error per document on a request you already cancelled. Without it, a deliberate cancellation silently turns into an unexplained error.

The last piece: the three bad terminal states — declined, expired and error — cannot just change a colour. In the connector they schedule a to-do activity for whoever created the request, telling them to decide whether to resend, extend or replace it. A decline nobody looks at is functionally identical to never being told.

Retries and failures: why a lost webhook is worse than a visible error

A visible error stops you. A lost webhook leaves you believing the document is still pending when it was signed days ago — or the other way round. The second one is far more expensive, because nobody goes looking for it.

Retries must be asymmetric. In the connector every call has a 30-second timeout by default, configurable. A read (GET) is retried up to twice, with growing back-off, on a 429, 500, 502, 503 or 504. A write (POST, PATCH, DELETE) is never retried: retrying a non-idempotent create means sending the same contract twice to the same signer. A visible error beats a silent duplicate. And one rule that is usually missing: an API redirect is treated as a hard error and never followed, because following it with the authorization header attached hands your token to whatever address Location names.

The webhook is not the truth: it is a doorbell. Signaturit does not cryptographically sign its webhooks — there is no HMAC — and its documentation describes no automatic retry policy; it does offer an endpoint to replay an event by hand. Given that, an inbound event in the connector is authenticated by a per-account token inside the URL itself, optionally restricted to the single source IP Signaturit publishes (one address, the same in sandbox and production), logged under a SHA-256 dedup key over the canonicalised JSON, and only then re-queried against the authenticated API. A duplicate delivery answers 200 and is not processed twice.

And if the event never arrives, there is a safety net: an hourly cron walks up to 200 pending requests and re-queries them. That single line is the real difference with a Zap. The Zap depends on the webhook; if the webhook is lost, there is nothing else.

The attachment that comes back: where it lands, under what name, with what audit

When the request reaches completed, two files come back, not one. The signed PDF is filed as <name>.signed.pdf and the audit trail as <name>.audit_trail.pdf, both attached to the request record, which in turn points back at the quotation, invoice or delivery note it came from. Neither of them ends up in anyone's inbox.

One detail that only shows up in production: the audit trail isn't always ready when the document is signed. Signaturit generates it separately and emits its own event when it becomes available. If the download fails, don't leave a gap: explicitly request generation and pick it up on the next cycle. A connector that downloads the signed PDF and forgets the trail leaves you with half the evidence. And if you asked the signer to upload documentation — ID card, proof of address — those files are downloaded separately, as a ZIP, onto the same record.

What to check before picking an approach

1. How many document types do you send for signature? One, a Zap. Four or more, each with its own PDF and recipient, and maintaining four Zaps already costs more than one module.
2. Does the signature state change any decision inside Odoo? If signing triggers invoicing, scheduling or onboarding, the ERP needs the state. If it only notifies someone, it doesn't.
3. Do you need the audit trail filed? If you may have to show it to an auditor or in a dispute, better it sits next to the invoice.
4. What happens if nobody looks at the dashboard for two weeks? Ask who gets a to-do when a contract expires unsigned. If the answer is “nobody”, you don't have an integration yet.
5. How many Odoo versions must you support? A Zap is version-agnostic; a module isn't, and the hr.contract → hr.version move is what that costs.
6. Does your Signaturit plan have API access? Without a token none of the three options work. Check that first.

Where all of this comes from

We have built seven modules on top of this integration: the core, which handles accounts, requests, recipients, events and archiving, plus six bridges for CRM, helpdesk, HR, projects, recruitment and inventory. 270 automated tests on the Odoo 19 branch, 262 on the 18 branch and 266 on the 17 one: the same code is maintained for all three versions at once.

None of the decisions in this article came from reading documentation. They came from successive QA rounds against the real connector: in a single round we fixed 23 defects found by testing it live plus 5 more from an adversarial audit against the API documentation; in the next round, 17 more. The module changelog lists them one by one, with dates. An autogenerated “product A × product B” page carries none of those scars, because nobody has ever run it.

Useful links within FlexigoTech

Frequently asked questions