📌
Availability
Bring Your Own Signature Provider currently has to be enabled per company, and is not on by default. Reach out to Ironclad support to have it enabled for your instance before you start building.
The integration also requires the Ironclad API entitlement, since your middleware authenticates against the public API to push status updates. If your instance does not have it, contact your Ironclad account representative.

📌
Audience
This guide is written for engineers building the third-party middleware that connects a custom eSignature provider to Ironclad. It assumes familiarity with the Ironclad Public API and API authentication.

Overview

Bring Your Own Signature Provider (BYOSP) lets your company route Ironclad signature requests through your own signing provider by standing up a middleware service that sits between Ironclad and that provider.

The integration has two directions of traffic:

Outbound (Ironclad → your middleware). Ironclad calls your middleware's HTTPS endpoints to initiate a signature request, cancel it, poll status, send reminders, and fetch the signed document. Every outbound request is signed; mTLS is optional.
Inbound (your middleware → Ironclad). Your middleware pushes signature lifecycle events to Ironclad's public API so Ironclad can update the signature request and drive the workflow forward.

Key Concepts

Term	Meaning
`endpointUrl`	The base callback URL you register in Ironclad. All middleware endpoints are implemented relative to this URL.
`signatureRequestId`	The signature request ID. A UUID that Ironclad generates at initiation and sends in the initiate body, then passes as the `{id}` path segment on the status, cancel, remind, and document calls. You send it back as the `{id}` path parameter on inbound pushes.
`roleName`	The only signer identifier on the wire. Ironclad's internal signer ID is never sent. `roleName` is unique within a request and must be echoed back on every status push.
Request status	The status of the signature request as a whole: `pending`, `completed`, or `voided`. Ironclad trusts this over any inference from individual signer states.
Signer status	An individual signer's state: `awaiting_signature`, `signed`, or `declined`.

Lifecycle

A workflow reaches its Sign step. Ironclad calls Initiate on your middleware, which creates the signature request with your provider and returns pending plus the initial signer states.
Throughout the request, Ironclad makes API calls to your middleware to send or request information (i.e. cancelling the request, reminding a signer who has not yet signed, polling your Status endpoint, or fetching the signed document). Each call carries a signature your middleware can verify. See Request Signing.
As signers act in your signature provider (i.e. viewing, signing, or declining), your middleware pushes status updates to Ironclad.
On completion, the request status becomes completed and Ironclad calls Document to retrieve the signed PDF.

What You Need to Build

Step	Guide
Register the provider and create a client app in Ironclad	Ironclad Setup
Implement the five outbound endpoints Ironclad calls	Middleware Endpoints
Verify Ironclad's request signature and document hashes	Request Signing
Push signature lifecycle events back to Ironclad	Status Updates

📌
Terms of Use
This guide and any software contained in it should be used at your own risk by individuals qualified to evaluate its effectiveness. IT IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL IRONCLAD BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH YOUR USE OF THIS GUIDE OR ANY SOFTWARE IT CONTAINS.
Your use of the Ironclad API must comply with Ironclad's API Terms of Use and the terms of the Enterprise Services Agreement (or equivalent) entered into between you and Ironclad.