Migrating from Dropbox Sign (HelloSign) API: A Developer's Guide

The HelloSign → Dropbox Sign rebrand: what actually changed

HelloSign launched in 2010 as a developer-friendly e-signature API. Dropbox acquired it in 2019 for $230 million, and in 2022 rebranded it to Dropbox Sign. For API users, the rebrand introduced three concrete changes:

1. New base URL. The API moved from api.hellosign.com to api.dropboxsign.com. The old domain still resolves with 301 redirects, but Dropbox has signalled it will be sunset entirely. If your integration relies on the old domain, every request is taking a redirect penalty.

2. OAuth 2.0 enforcement. HelloSign's original API used simple API key authentication — you passed your key as the username in HTTP Basic auth. Dropbox Sign now requires OAuth 2.0 for any integration that accesses accounts on behalf of users. For embedded signing flows, you need to implement the full authorization code grant with PKCE.

3. SDK overhaul. The legacy hellosign-sdk npm package was deprecated. The replacement, @dropbox/sign, is auto-generated from an OpenAPI spec and has a significantly different API surface. Method names, parameter structures, and error handling all changed. If you were using the HelloSign SDK, you are effectively learning a new SDK from scratch.

The net effect: developers who chose HelloSign for its simplicity are now maintaining an integration with the complexity of DocuSign. Many teams use this forced migration as an opportunity to re-evaluate their e-signature API entirely.

Authentication: Dropbox Sign OAuth vs Signbee Bearer auth

This is where the migration pain concentrates. Here's what each flow requires:

For server-to-server integrations (the most common use case for e-signature APIs), Dropbox Sign's OAuth adds roughly 200-400 lines of token management code that serves no functional purpose beyond authentication. Signbee eliminates this entirely.

Endpoint mapping: Dropbox Sign → Signbee

Here is a direct mapping of the Dropbox Sign API endpoints you are most likely using to their Signbee equivalents. The key difference: Signbee collapses most of these into a single endpoint with different request body parameters.

Notice the pattern: Dropbox Sign requires 9+ endpoints for a standard signing workflow. Signbee uses 3 (/send, /documents, /documents/:id/pdf). Templates are not a separate API resource — they are markdown strings in your codebase, which means they are version-controlled, testable, and do not require a separate dashboard.

Code migration: before and after

Here is a real-world example — sending a document for signature using a template. This is the most common Dropbox Sign API operation.

import * as DropboxSign from "@dropbox/sign";

const signatureRequestApi = new DropboxSign.SignatureRequestApi();
signatureRequestApi.username = "YOUR_ACCESS_TOKEN"; // OAuth token

const signer: DropboxSign.SubSignatureRequestTemplateSigner = {
  role: "Client",
  emailAddress: "jane@example.com",
  name: "Jane Smith",
};

const customField: DropboxSign.SubCustomField = {
  name: "project_name",
  value: "Website Redesign",
  editor: "sender",
  required: true,
};

const data: DropboxSign.SignatureRequestSendWithTemplateRequest = {
  templateIds: ["tmpl_abc123def456"],
  subject: "Service Agreement",
  message: "Please review and sign this agreement.",
  signers: [signer],
  customFields: [customField],
  clientId: "YOUR_CLIENT_ID",  // Required for embedded
  testMode: true,
};

try {
  const result = await signatureRequestApi.signatureRequestSendWithTemplate(data);
  const signatureRequestId = result.body.signatureRequest?.signatureRequestId;
  
  // Now get the embedded signing URL (separate API call)
  const signerId = result.body.signatureRequest?.signatures?.[0]?.signatureId;
  const embeddedApi = new DropboxSign.EmbeddedApi();
  embeddedApi.username = "YOUR_ACCESS_TOKEN";
  const signUrl = await embeddedApi.embeddedSignUrl(signerId!);
  
  console.log("Sign URL:", signUrl.body.embedded?.signUrl);
} catch (error) {
  if (error instanceof DropboxSign.HttpError) {
    // Handle OAuth token expiry, rate limits, etc.
    console.error(error.statusCode, error.body);
  }
}

const res = await fetch("https://signb.ee/api/v1/send", {
  method: "POST",
  headers: {
    "Content-Type": "application/json",
    "Authorization": "Bearer YOUR_API_KEY",  // No OAuth. No refresh.
  },
  body: JSON.stringify({
    markdown: [
      "# Service Agreement",
      "",
      "**Project:** Website Redesign",
      "",
      "This agreement confirms that the undersigned agrees to the terms",
      "outlined in the attached statement of work.",
      "",
      "---",
      "",
      "**Client signature:**",
    ].join("\n"),
    recipient_name: "Jane Smith",
    recipient_email: "jane@example.com",
    subject: "Service Agreement",
  }),
});

const { document_id, signing_url, status } = await res.json();
console.log("Sign URL:", signing_url);
// That's it. No second API call. No SDK. No template dashboard.

The Dropbox Sign version requires an SDK import, OAuth token management, template ID lookup, a separate API call for the embedded signing URL, and typed error handling for OAuth edge cases. The Signbee version is a single fetch call. The template is a markdown string — if you need to change the wording, you change a string in your codebase, not a template in a dashboard.

Webhook migration: Dropbox Sign vs Signbee events

Webhook events are where migrations get tricky if you have downstream logic that depends on specific event names or payload shapes. Here is a direct mapping of Dropbox Sign callback events to Signbee webhook events:

Key difference: verification. Dropbox Sign uses an API key hash to verify webhook authenticity — you compute an HMAC of the event type using your API key and compare it to the hash in the payload. Signbee uses HMAC-SHA256 with a dedicated webhook secret sent in the X-Signbee-Signature header. The verification logic is simpler and follows the same pattern used by Stripe and GitHub:

// Dropbox Sign: hash-based verification
const crypto = require('crypto');

app.post('/webhook/dropboxsign', (req, res) => {
  const eventHash = req.body.event.event_hash;
  const eventType = req.body.event.event_type;
  const apiKey = process.env.DROPBOX_SIGN_API_KEY;
  
  const computedHash = crypto
    .createHmac('sha256', apiKey)
    .update(eventType)
    .digest('hex');
  
  if (computedHash !== eventHash) {
    return res.status(401).send('Invalid signature');
  }
  
  // Process event...
  res.send('Hello API Event Received');  // Must return this exact string
});

// Signbee: HMAC-SHA256, same pattern as Stripe
const crypto = require('crypto');

app.post('/webhook/signbee', (req, res) => {
  const signature = req.headers['x-signbee-signature'];
  const rawBody = req.rawBody;  // Must use raw body, not parsed JSON
  
  const expected = crypto
    .createHmac('sha256', process.env.SIGNBEE_WEBHOOK_SECRET)
    .update(rawBody)
    .digest('hex');
  
  if (!crypto.timingSafeEqual(Buffer.from(signature), Buffer.from(expected))) {
    return res.status(401).send('Invalid signature');
  }
  
  const event = JSON.parse(rawBody);
  // event.type === "document.signed" | "document.completed" | etc.
  res.status(200).send('ok');
});

Note: Dropbox Sign requires you to return the exact string "Hello API Event Received" in your webhook response. Any other response causes retries. Signbee accepts any 2xx status code, which is the industry standard pattern.

Common migration pitfalls

Migration checklist

Frequently Asked Questions

Last updated: July 7, 2026 · Michael Beckett is the founder of Signbee and B2bee Ltd.