You can ship e-signatures without running any signing infrastructure of your own. No document database, no signing UI, no certificate handling, and no tamper-evident audit log to maintain. A single serverless function or edge route is enough to send a document out for signature, and that is exactly the kind of footprint a side project or an MVP wants.
The shortcut: use a hosted e-signature API. With TurboDocx, signing, delivery, audit trails, and compliance run on TurboDocx infrastructure. Your job shrinks to one thing, which is making an API call from somewhere safe. That “somewhere” does not have to be a backend you own.
What “no backend” actually means
You still need a place to make the call, because your API key must never live in client-side code. But that place can be tiny and serverless. Any of these is enough:
Serverless function
A Vercel, Netlify, or Lambda function that fires when a form submits or a deal closes.
Edge / route handler
A Next.js route handler or edge function that proxies the request and keeps your key server-side.
A one-off script
A Node or Python script you run from your laptop or a cron job. No web server at all.
Let the agent write the call
The fastest path is to let your AI coding agent write the integration. Install the TurboDocx Quickstart Skill, then describe what you want. The skill detects whether you are on Next.js, Express, a serverless function, or plain Node, and writes a call that fits.
npx skills add TurboDocx/quickstart
Then, in your agent: “Add a serverless function that sends a PDF for signature with TurboSign.” Step-by-step versions live in the Claude Code guide and the Cursor guide. If you would rather see the raw SDK call, the JavaScript guide has it.
The whole thing in one serverless function
Here is the entire feature as a single Next.js route handler. The same shape works as a Vercel function, a Netlify function, or a Lambda: parse the request, configure the SDK from environment variables, and call sendSignature. There is no document database to set up, no signing page to build, and no audit trail to store. The recipient gets an email with a signing link, and TurboSign takes it from there.
// app/api/send-signature/route.ts
import { TurboSign } from '@turbodocx/sdk';
import { readFileSync } from 'fs';
TurboSign.configure({
apiKey: process.env.TURBODOCX_API_KEY, // server-side only
orgId: process.env.TURBODOCX_ORG_ID,
senderEmail: process.env.TURBODOCX_SENDER_EMAIL,
senderName: process.env.TURBODOCX_SENDER_NAME,
});
export async function POST(request: Request) {
const { recipientName, recipientEmail } = await request.json();
// Validate the incoming request before you spend a signature
if (!recipientEmail) {
return Response.json({ error: 'recipientEmail required' }, { status: 400 });
}
const pdfBuffer = readFileSync('contract.pdf');
const result = await TurboSign.sendSignature({
file: pdfBuffer,
documentName: 'Partnership Agreement',
recipients: [{ name: recipientName, email: recipientEmail, signingOrder: 1 }],
fields: [
{
type: 'signature',
recipientEmail,
template: { anchor: '{signature1}', placement: 'replace', size: { width: 100, height: 30 } },
},
],
});
return Response.json({ documentId: result.documentId });
}That single file is the whole integration. For the full reference (every field option, recipient setting, and template anchor), see the standalone TypeScript signing guide.
Notice that the API key is read from process.env inside the function and never leaves the server. Never call the signing API from the browser, and never ship TURBODOCX_API_KEY in your frontend bundle or a NEXT_PUBLIC_ variable. A leaked key is not just an account detail: anyone who has it can send signature requests on your behalf, spend your quota, and put your name on documents you never authorized. The key belongs in exactly one place, which is the serverless function’s environment.
It is also worth being honest about the phrase “no backend.” What you are really doing is borrowing someone else’s backend, the hosted signing API, so you do not have to run one yourself. That is a great trade, but it does not remove every responsibility. You still own the request that triggers the call. Validate the inputs (the snippet above rejects a missing recipient before spending a signature) and authenticate the caller so a stranger cannot hit your route and fire off documents in your name. The signing infrastructure is outsourced; the gate in front of it is yours. For the full SDK surface and field options, see the JavaScript guide, or install the Quickstart Skill and let your agent wire it up.
The one rule: keep the key off the client
“No backend” does not mean “call the API from the browser.” Your API key grants access to your account, so it has to stay server-side, even if that server is a function that runs for 200 milliseconds. Read it from an environment variable, never bake it into your frontend bundle, and let the serverless layer be the only thing that talks to the signing API. The Quickstart Skill follows this rule by default, reading your key from .env rather than hardcoding it.
Everything else that makes signatures legally defensible, including tamper-evident audit trails and ESIGN, UETA, and eIDAS alignment, is handled on the API side. You can read more on the US compliance and European compliance guides.
Related Resources
Add signing without the infrastructure
Install the Quickstart Skill and let your agent write the call. Your first 5 signatures each month are free.