How to Add E-Signatures to Anything You Build With Claude Code

You're building with Claude Code, and at some point a user needs to sign something. A contract, an NDA, a consent form, an order. The usual answer is to bolt on a heavyweight signing vendor, sit through a sales cycle, and accept per-seat pricing that doesn't fit a product still finding its shape. There's a cleaner path. Firma.dev is an e-signature API you can wire into whatever you're building, and the full implementation steps live in the Claude Code integration guide so you can hand them straight to whoever writes the code.

This piece is for founders and evaluators deciding whether the approach fits. It stays out of the code and focuses on what becomes possible, what it costs, and how the pieces fit together.

What Claude Code plus Firma.dev actually lets you do

The outcome first: you can have legally binding signing live inside your product without hiring a signing vendor or sitting through a sales cycle. Your app sends a document, the signer gets a link, they sign, and you get a completed file plus an audit trail that records who signed and when. The signing screen can be embedded in your own UI, so users never leave your product to complete a signature.

Because there is no signing vendor sitting between you and your users, the experience stays inside your product. Signers don't bounce out to a third-party brand, and the flow looks like part of the app rather than a detour through someone else's tool.

What an MCP server is, in plain terms

An MCP server is a connection that lets an AI tool like Claude Code work with an outside service in a structured way, rather than guessing at how that service behaves. Firma.dev runs two of them. The first, the Docs MCP, lets Claude Code read the live Firma.dev documentation so it writes integration code that's actually correct, not approximated from memory. The second, the Data MCP, lets it operate on your Firma.dev data directly, sending signing requests and managing templates.

You don't need to understand the plumbing to benefit from it. The short version is that connecting these servers gives Claude Code an accurate, current picture of how Firma.dev works, which is what lets it build the integration reliably instead of producing code you then have to debug against stale assumptions.

What you can ask Claude Code to build

In plain language, the things a builder asks for tend to be the same handful of jobs. Send a contract out for signature when a user takes an action in your app. Drop a signing screen inside your own interface so the signer stays in your product. Get a notification when a document comes back signed, so the next step in your workflow can fire automatically.

These are real prompts you can give Claude Code with the Firma.dev servers connected, and it works against the live API to build them. The exact steps, including how to connect the servers and what to ask for, are in the official Claude Code guide. This post points you there rather than reprinting the code.

Why this is cheaper than the alternative

Firma.dev is pay-as-you-go at EUR 0.029 per envelope, which is roughly 3 cents USD. You pay for the documents you actually send, with no upfront cost, no monthly minimum, and no annual contract to sign before you can start. An envelope is a single signing request, so a document going to one signer or several signers counts as one envelope.

Compare that to the enterprise signing model, where pricing is built around per-seat licenses and tiered annual plans. That structure assumes a fixed set of internal users sending documents, which is the wrong shape for a SaaS product where signing volume rises and falls with your own customers' activity. Paying per envelope means your signing cost tracks usage directly, and a quiet month costs you almost nothing. For a product still growing, that difference compounds.

Built for products with many customers

If what you build serves multiple customers, you'll want their documents and templates kept apart. Firma.dev handles this with Customer Workspaces, which are private, partitioned spaces inside your account. Each customer gets isolated templates and their own envelope usage, so one customer's contracts and signing activity never mix with another's.

This matters for two reasons. The first is clean separation, which keeps each customer's data where it belongs and makes per-customer reporting straightforward. The second is that it scales with you. As you add customers, you add workspaces, without rearchitecting how signing works in your app. The structure is built for the multi-customer case from the start rather than retrofitted later.

Compliance, briefly

Firma.dev is designed for the major electronic signature frameworks. In the United States that means the ESIGN Act and UETA. In Europe it means eIDAS, supporting Simple Electronic Signatures and Advanced Electronic Signatures, and it is built to help you comply with GDPR for the personal data involved in a signing flow.

Every completed signature comes with an audit trail recording the signing events, which is the record you'd point to if a signature were ever questioned. If your specific use case has regulatory requirements beyond the common frameworks, it's worth confirming the details against your own legal guidance before you build. The point here is that legally binding signing is the baseline, not an add-on you have to engineer yourself.

Get started

If you're building with Claude Code and you want signing inside your product, the path is short. Start with the Claude Code integration guide for the implementation, and read the MCP server announcement if you want the background on how the servers work. The same approach works across the other AI building tools too, so the e-signing layer you add to a Lovable app, a Bolt project, or something in Cursor looks much the same.

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