If you run Scrive and you run Odoo, there is no listing to click. Scrive's own integrations directory names dozens of systems — Salesforce, HubSpot, Dynamics 365, Teamtailor, SD Worx, Zapier, Make, Microsoft Teams — and Odoo is not one of them; what it offers instead is a form to request one. Search for a Scrive Odoo integration and you get generic Odoo-integration pages from consultancies and automation platforms, plus Scrive's own integrations page, which does not list Odoo either. Nobody has written the answer down, so here it is: what a real Scrive connector for Odoo does, endpoint by endpoint, and what it does not do yet.
Who is writing this. FlexigoTech is an official Scrive System Partner (Scrive AB, Sweden), see our partners page. We built the connector described below and we maintain it. This describes an integration that exists and runs — not an App Store listing and not an availability announcement. Where something is only proven against test fixtures rather than a live Scrive account, it says so; a section below does nothing else.
Scrive integrates with dozens of systems. Why not Odoo?
Nothing technical is in the way: Scrive publishes a Document API v2 and a separate OAuth2 service, both ordinary REST over HTTPS. Everything below is built on those two. Why the directory has no Odoo entry is a commercial question and not ours to answer; what we can answer is what building it takes.
It takes more than one module, and that gets its own section below: an Odoo connector is not one piece of software. Odoo supports three major versions at a time and a module written for Odoo 19 does not install on Odoo 17, so whoever builds it maintains it three times over. Odoo Enterprise does ship a native Sign app, and for internal acknowledgements it is enough — but it does not talk to BankID, MitID or the Finnish Trust Network, and it does not produce a sealed evidence package from a provider your compliance officer already accepts.
Which Odoo document actually goes out for signature
The connector adds no separate signature silo to feed by hand. It adds a mixin to the records that already carry the content worth signing, so the send button lives on the record itself:
- Quotations and sales orders (sale.order), signed before they become confirmed orders.
- Invoices and other journal entries (account.move).
- Purchase orders (purchase.order) — the supplier side of the same problem.
- Employment documents: hr.version on Odoo 19, hr.contract on 18 and 17.
- Delivery notes (stock.picking) — proof of delivery signed where it happens.
- Work acceptance on project tasks (project.task), on plain Community Project rather than the Enterprise-only Field Service app.
From any of those, a wizard opens with the PDF Odoo already knows how to print, the parties pre-filled from the record's partner, the signing order, the document language and, per party, the authentication method. Parties can carry extra fields the signer must complete — checkbox, radio group or free text, the three Scrive's API supports. There is no native date type, and a radio group caps at eight options.
Authentication: three ways in, and what each one costs you
This is where these projects get stuck. The connector offers three connection modes and they are not equivalent.
1. Personal Access Credentials
Four static tokens: an API token and secret plus an access token and secret. The connector fetches all four for you — you enter your Scrive login in a wizard, it calls the personal-token endpoint, and the credentials land on the account record behind a manager-only field group. No redirect URIs, no client registration, nobody to wait on. This is the mode we have round-tripped against a real Scrive testbed account: tokens fetched from a real login, documents sent, signed and sealed.
2. OAuth2 with your own Scrive OAuth2 client
Authorization code plus refresh token, scope doc:create doc:check doc:send offline_access. Two traps. Scrive's OAuth2 endpoints sit on a different subdomain from the Document API — the API is scrive.com or api-testbed.scrive.com, the OAuth2 host is oauth2.scrive.com or oauth2.api-testbed.scrive.com — and pointing one at the other produces errors that look like credential problems and are not. And the token endpoint rejects client_id and client_secret in the form body with a flat 401: it wants HTTP Basic client authentication. We found that by reading a live 401. The structural limit of this mode: Scrive registers one redirect URI per client, and every customer's Odoo has its own domain.
3. One-click connection through a relay
A relay owns the single registered redirect URI and hands each Odoo database a scoped connection handle, so no shared client secret ever reaches a customer database. The plain OAuth2 flow it wraps has been exercised against Scrive's live authorization endpoint on the testbed with a real Scrive-issued client. The relay itself is not finished: its callback URL still has to be registered on Scrive's side, so we do not describe this mode as working.
The API surface the connector actually uses
These are the Document API v2 endpoints it calls:
| Stage | Endpoints | What it does |
|---|---|---|
| Prepare | documents/new · {id}/setfile · {id}/update · newfromtemplate/{id} · {id}/setattachments | Creates the Scrive document from the Odoo PDF and writes parties, fields, language and authentication methods — or starts from a Scrive template. |
| Send | {id}/start · {id}/setautoreminder | Moves the document to Pending and optionally arms Scrive's automatic reminder. |
| Follow | {id}/get · documents/list · {id}/callback | Reads state back; the list endpoint also imports documents created outside Odoo. |
| Correct in flight | {id}/remind · prolong · restart · cancel · trash · forward · {signatory}/resend · changeemailandmobile · getqrcode | The unglamorous half of e-signing: wrong address, deadline tomorrow, wrong person — all from the Odoo record. |
| Retrieve | {id}/files/main/{filename} · {id}/files/zip/{filename} | The sealed PDF, and the full evidence package as a ZIP. |
| Account | getpersonaltoken · usagestats/days | Fetches the four personal credentials and reads Scrive usage back into Odoo. |
Two notes on how those calls are made. Every document carries two mandatory Scrive System Partner tags — a system partner name and an integration name — which is how Scrive attributes traffic to the partner that built the integration; both are constants in the code. And outbound requests do not follow redirects: any 3xx from an API host is rejected rather than chased.
What comes back, where it lands, and what the audit trail is
Two mechanisms bring state back, and having both is the point. Scrive calls a callback URL on your Odoo, scoped per account and protected by a rotatable token in the path. Because callbacks get lost, an hourly cron also polls anything still pending.
The Odoo record mirrors Scrive's lifecycle instead of flattening it to sent/signed: Draft, Preparation, Awaiting Start, Pending, Signed, Canceled, Timed Out, Rejected, Error and Saved as Template. “Timed Out” and “Rejected” are different conversations. Every callback is stored as its own row with the event id, the raw payload and whether it processed cleanly; duplicate deliveries are stopped by a unique database constraint. A daily cron prunes those rows after a configurable window, ninety days by default.
Once signed and sealed, the connector downloads the sealed PDF and attaches it to the Odoo record it came from, retrying the documented race where the sealed file is not ready the instant the callback fires. The full evidence package — sealed PDF, evidence log, attachments — is one button away as a ZIP. In a dispute it is Scrive's evidence log that carries weight. Odoo's chatter tells you who pressed send; it is not the audit trail.
Nordic specifics: BankID, MitID, and why “signed” means three things
Scrive's Document API separates authentication to view a document from authentication to sign it, and the two lists differ. Fifteen values let someone view: no eID at all, SMS PIN, Swedish and Norwegian BankID, Danish MitID and MitID Erhverv, the Finnish Trust Network, iDIN, Freja eID and OrgID, and document-based identity checks. Twenty let someone sign: the same list with plain Verimi swapped for its qualified variant, plus five qualified options — Norwegian BankID at QES grade, itsme, Smart-ID and Scrive's own qualified signature in two flavours.
That split is the whole eIDAS conversation in one data structure. Under Regulation (EU) 910/2014 a simple, an advanced and a qualified signature are three legal categories, and only the qualified one has, under Article 25(2), the equivalent legal effect of a handwritten signature across the EU. In Scrive's API that distinction is not a setting buried in an account — it is which value you put on the party. Norwegian BankID and Norwegian BankID (QES) are two different strings. Send the wrong one and the document is still signed, just at a level your legal department did not ask for. Our companion piece on SES, AES and QES in Odoo covers the legal side properly.
Two details the connector enforces rather than discovers the hard way. Swedish BankID needs the signer's personal number, so the connector refuses to send a BankID party without one rather than let the call fail on Scrive's side. And Scrive's nineteen document languages include Swedish, Norwegian, Danish, Finnish and Dutch; the connector maps the partner's Odoo locale onto that list — bokmål and nynorsk included — so the signing page opens in the signer's language.
Running the same connector on Odoo 19, 18 and 17
“Supports Odoo 17 to 19” is not a line in a manifest; it is three branches that genuinely differ. Four examples, each enough on its own to stop a module installing on the wrong version:
| What differs | Odoo 19 | Odoo 18 and 17 |
|---|---|---|
| Employment record | hr.version | hr.contract — same feature, different model, so the HR bridge is written separately on each branch |
| Security groups | res.groups.privilege groups the access rights | A plain res.groups with a module category; the 19 security file does not load at all |
| SQL constraints | models.Constraint class attributes | The older _sql_constraints list |
| List views | <list>, on Odoo 18 as well | Odoo 17 still wants <tree>, and its validator insists any field used by a modifier is present in the view, even invisible |
The only way to keep that honest is to run the tests on each version instead of assuming the port worked. The core module carries 241 automated tests, and the same 241 exist on the 19.0, 18.0 and 17.0 branches — 255 across all four modules on Odoo 19, 253 on 18 and 17, the difference being version-specific bridge tests.
What is proven against the real Scrive API, and what is not
A green test suite is a claim about your own code, not about the other side's server. Here is the split:
| Status | What that covers |
|---|---|
| Verified against the live API | Personal Access Credentials against a real Scrive testbed account: the four tokens fetched from a real login, documents sent, signed and sealed, and Scrive's own delivery errors read back into Odoo. Plus the OAuth2 authorization flow against the same testbed with a real Scrive-issued client, including the HTTP Basic token-endpoint requirement, found by reading a live 401. Production scrive.com has not been exercised. |
| Verified against fixtures only | The 241-test suite. It patches the HTTP client at the seam and replays payload shapes from the Document API v2 reference and the eID Hub OpenAPI specification. That proves the connector behaves correctly given those shapes. It does not prove Scrive returns those shapes for your account. |
| Not proven end-to-end | The one-click relayed OAuth2 connection. It reaches Scrive's real authorization endpoint and the client is recognised, but the relay's redirect URI is not registered on Scrive's side yet. Treat it as unfinished. |
Ask any e-signature connector for that same split, in writing. “Fully integrated” next to a mocked test suite is the claim worth checking.
Where this does not fit
- You only sign internal acknowledgements and you are already on Odoo Enterprise. Its native Sign app is enough and costs nothing extra.
- You are not already a Scrive customer. The connector is not a reason to become one — the eID coverage is, or it is not. Choose the provider first, then integrate.
- Your documents are generated outside Odoo, in a policy administration or core banking platform. Signing from Odoo would then mean moving document generation into Odoo — a far bigger project than a connector.
- You need a qualified signature in a country Scrive's sign-authentication list does not cover. Check that list against your jurisdictions before anyone writes code.
- Your Odoo is a heavy fork. The connector assumes stock Odoo 19, 18 or 17 models; budget for the fork, not for the connector.
Useful links within FlexigoTech
Frequently asked questions
Does Scrive have an official Odoo integration?
No. Scrive's own integrations directory names dozens of systems and Odoo is not among them. FlexigoTech is an official Scrive System Partner and has built and maintains a Scrive connector for Odoo 19, 18 and 17. It is not published on the Odoo App Store, so the way to see it is to ask us for a walkthrough.
Which Odoo versions does the connector support?
Odoo 19, 18 and 17, as three separate branches rather than one branch with version switches. The core module carries 241 automated tests on each branch. The differences are real: the employment record is hr.version on 19 and hr.contract on 18 and 17, and security groups use res.groups.privilege only on 19.
Can I sign with Swedish BankID or Danish MitID from inside Odoo?
Yes, because those are values in Scrive's own Document API. The connector exposes Scrive's authentication-to-view list (fifteen methods, including Swedish BankID, Norwegian BankID, Danish MitID, MitID Erhverv, the Finnish Trust Network and iDIN) and its authentication-to-sign list (twenty methods) as fields on each signing party.
Does a BankID signature count as a qualified signature under eIDAS?
Not automatically. Scrive's API treats Norwegian BankID and Norwegian BankID (QES) as two different values, and the qualified options exist only in the authentication-to-sign list. The same national eID can therefore produce signatures at different eIDAS assurance levels, so a qualified signature has to be chosen deliberately.
What is proven against the live Scrive API and what is only proven against fixtures?
Proven live against a real Scrive testbed account: Personal Access Credentials, documents sent, signed and sealed, and the OAuth2 authorization flow with a real Scrive-issued client, including the HTTP Basic requirement on the token endpoint. Proven against fixtures only: the 241-test suite, which patches the HTTP client and replays payload shapes from the Document API v2 reference. Not proven end-to-end: production scrive.com and the relayed one-click OAuth2 mode.
Using Scrive and Odoo?
Tell us which documents you sign, in which countries and at which eIDAS level, and we will tell you on the first call what the integration looks like and what it does not solve. Email comercial@flexigobe.com or call +34 616 809 504.