Completion Page Customization: Redirect Signers Back Into Your App After They Sign

For most e-signature tools, a signer who finishes signing lands on a generic "thanks for signing" page that has nothing to do with the workflow that brought them there. For an embedded integration, that's the one moment in an otherwise smooth flow where control quietly slips out of your hands, right when you'd want it back the most.

Firma.dev's new completion page customization closes that gap. You can now set a custom title, a custom message, and an auto-redirect URL for what happens the instant a signer completes their signature, configurable at the company, workspace, template, or individual signing request level.

The dead end at the end of signing

Embedded signing flows are usually seamless right up until the last click. A signer opens a document inside your CRM, your onboarding tool, or your billing platform, signs it, and lands on Firma.dev's default completion screen with no path back to where they started. If your product depends on that signer continuing somewhere else, finishing onboarding, returning to a deal page, confirming a subscription, that screen has been a real hole in the experience since the day you shipped the integration.

It's easy to miss in a demo, since everything up to that point has occured exactly as expected. The signing itself works, the document looks right, the API call succeeds. Then someone actually signs a document end to end and asks where the "back to app" button is. There wasn't one.

Four settings, one cascade

The fix is four new fields:

• completion_title (up to 200 characters)

• completion_message (up to 1000 characters)

• completion_redirect_url (HTTPS only, up to 2000 characters)

• completion_redirect_delay (0 to 30 seconds)

Each field resolves independently through a cascade: company, then workspace, then template, then individual signing request, with the most specific setting always winning. A workspace can set a default completion message for every request it sends, while a single template overrides just the redirect URL underneath it and leaves everything else alone, since each field is stored and resolved seperately. Set your defaults once at the company level and override only where a specific workflow actually needs something different... you shouldn't have to configure four fields on every template just to change one of them.

Built with a time limit

The redirect isn't permanent. It stays valid for 10 minutes after a signer completes their document, specifically so a signing link can't get reused as a general-purpose redirect months later, long after the actual signing event is over. Add the HTTPS-only requirement on the redirect field, and it's a small, deliberate constraint on the feature. Audit trails and identity verification are the heavier security tools in Firma.dev's stack; this is a lighter constraint that closes one obvious misuse path without adding friction to how the feature gets used day to day.

Where this actually shows up

A few patterns we'd expect teams to reach for right away:

• Back into the host app. A signer finishes an NDA inside your CRM and lands straight back on the deal page, not stuck looking at a browser tab from Firma.dev they now have to close manually.

• Per-template routing. NDA signers get redirected to an onboarding flow. Contract signers land on a billing page instead. Same account, two different destinations, because the setting lives on the template rather than the workspace.

• Branded completion copy. Swap the generic "you're done" text for something that sounds like your own company wrote it, even on requests where you never touch the redirect at all.

Picture a legal tech platform with embedded signing built on Firma.dev's customer workspaces: NDAs route new hires into an onboarding checklist, while signed service agreements route straight to the client's billing page. Two templates, two settings, zero custom logic on your end to detect which document just got signed.

Setting it up

In the dashboard, it lives under Workspace Settings in a new Completion Page section, or per template inside the Template Editor's Document Settings tab. Through the API, the same four fields sit on:

POST/PUT/PATCH /signing-requests
POST/PUT/PATCH /templates
PUT /workspace/{id}/settings
PUT /company/settings

POST/PUT/PATCH /signing-requests
POST/PUT/PATCH /templates
PUT /workspace/{id}/settings
PUT /company/settings

POST/PUT/PATCH /signing-requests
POST/PUT/PATCH /templates
PUT /workspace/{id}/settings
PUT /company/settings

A minimal example, setting a redirect on a single signing request:

{
  "completion_title": "You're all set",
  "completion_redirect_url": "https://app.yourcompany.com/deals/482910",
  "completion_redirect_delay": 3
}

{
  "completion_title": "You're all set",
  "completion_redirect_url": "https://app.yourcompany.com/deals/482910",
  "completion_redirect_delay": 3
}

{
  "completion_title": "You're all set",
  "completion_redirect_url": "https://app.yourcompany.com/deals/482910",
  "completion_redirect_delay": 3
}

Three seconds is usually enough for the confirmation message to register before the redirect fires. Longer delays work too, up to the 30 second cap, if you'd rather the signer actually read the page first.

If you're setting this up for the first time, our embedded signing quickstart walks through the rest of the integration around it.

If you do nothing, nothing changes

Leave these fields unset and the existing translated completion page renders exactly as it always has, in whichever of Firma.dev's 14 supported languages the signer happens to be using. This shipped alongside API v1.34.0, with no migration step, no opt-in flag, and no visual change for anyone who isn't using it yet.

For a SaaS product embedding e-signature into its own flow, this is the kind of detail that decides whether the integration feels bolted on or built in. The redirect used to be an afterthought... now it's a config field.

Get started with Firma.dev for free, no credit card required.