Founder of SumoSign. Writes on electronic signatures, agent-native signing workflows, and evidence-grade contract execution for contract-heavy teams.
Signbee Review 2026: API, MCP, Pricing & Limits
A documentation-based Signbee review covering its API, MCP server, pricing, two-party signing flow, certificate, strengths, limits, and alternatives.
The direct verdict: Signbee is a compelling low-cost e-signature API for developers and AI-agent builders whose recurring job is to send one document between one sender and one recipient. Its markdown input, optional API key, documented four-endpoint REST surface, and published MCP package remove setup from that narrow workflow. It is a weaker fit when agreements require several signers, reusable roles, ordered approvals, advanced branding, enterprise administration, or qualified electronic signatures.
This is a documentation-based Signbee review, not a hands-on product test. No live document was sent, no signing ceremony was completed, and no certificate, delivery time, support response, or production reliability was independently tested. The findings come from Signbee's public homepage, documentation, about page, terms, and llms.txt, rechecked on July 18, 2026. Product and legal statements from those pages are identified as vendor claims; practical judgments are editorial conclusions.
Signbee review summary
| Review question | Documentation-based finding | Assessment type |
|---|---|---|
| What is Signbee best at? | Sending markdown or a hosted PDF through a simple two-party signing flow | Verified in public documentation |
| Who is it best for? | Developers, indie teams, agent builders, and low-volume automations with one recipient | Editorial conclusion |
| What is the main limitation? | The documented request accepts one recipient and does not describe multi-party routing | Verified documentation scope |
| Does it support MCP? | Yes; the published signbee-mcp package exposes markdown and PDF send tools | Verified publication claim; not execution-tested |
| Is there a free plan? | Yes; public pages list five documents per month | Verified first-party pricing |
| What does Business cost? | $19 or $29 per month, depending on which live first-party page is read | Unresolved first-party discrepancy |
| Was reliability tested? | No; the terms state a 99.9% target but do not guarantee it | Not independently verified |
| Overall verdict | Strong specialist option for simple two-party sends; evaluate another product for deeper workflows | Editorial conclusion |
How this review separates facts, claims, and conclusions
| Label | Meaning in this review | Example |
|---|---|---|
| Verified documentation fact | Present on a live first-party page retrieved for this review | POST /api/v1/send accepts markdown or a PDF URL |
| Signbee vendor claim | A statement made by Signbee that was not independently tested or certified here | The completed PDF includes the described SHA-256 certificate and metadata |
| Editorial conclusion | Our interpretation of the documented workflow for a buyer's use case | Signbee is a good fit for one-off, two-party agreements |
| Unresolved | First-party materials conflict or omit information needed for a firm conclusion | Business is shown at both $19 and $29 per month |
This distinction matters because a well-written API page can prove that an interface is documented, but not that emails arrive quickly, examples work without adjustment, the mobile ceremony is clear, or the service meets a buyer's uptime needs. MCP presence, endpoint count, OpenAPI, and llms.txt likewise show integration intent and discoverability; none is evidence of product quality on its own.
What Signbee is
Signbee is an API-first e-signature service operated by B2bee Ltd and positioned for developers and AI agents. The public workflow accepts document content, verifies a sender, emails one recipient, collects the recipient's signature, and returns a completed PDF. Signbee exposes that workflow through REST, an MCP server, an Agent Skill, an OpenAPI specification, and machine-readable llms.txt.
Its defining product decision is scope. Signbee documents two-party e-signing rather than a configurable envelope with many recipients. A request contains one recipient, while the lifecycle moves from pending_sender to pending_recipient and then signed. That model can be an advantage when it matches the job: there are fewer resources and states for an integration to manage. It becomes a functional boundary when the real agreement needs legal, finance, a client, and a countersigner in one coordinated process.
Features at a glance
| Capability | What the live documentation says | Review assessment |
|---|---|---|
| Document input | Markdown from 10 characters to 50KB, or a URL to an existing PDF | Useful for generated agreements and already-hosted PDFs |
| PDF preview | A separate generate endpoint converts markdown without starting signing | Helpful for inspecting output before a send |
| Sender authentication | API key pre-verifies the sender; no-key mode uses sender email OTP | Flexible for both prototypes and automated sends |
| Recipient workflow | One recipient receives an email link, reviews, and signs | Clear two-party scope; not documented as multi-party |
| Expiration | Seven days by default, configurable up to 30 days | Adequate basic control for pending links |
| Status tracking | Authenticated GET returns status, party details, dates, and PDF URLs | Polling is documented; webhooks are not |
| Revocation | Authenticated DELETE revokes a pending document | Covers basic cancellation before recipient signature |
| MCP | Public npm package with tools for markdown and PDF sends | Promising agent interface, but not run in this review |
| Completion evidence | Signbee claims a SHA-256 certificate and signing metadata | Potentially useful; the actual artifact was not inspected |
| Templates and fields | No reusable template library or visual field builder is described | Ask the vendor if prepared-template workflows are required |
| Branding | Custom domains and detailed branding controls are not documented on reviewed pages | An open procurement question, not proof of absence |
| QES | Terms identify the product as Simple Electronic Signatures | Use a qualified trust service provider when QES is mandatory |
Signbee API review
The REST API is the clearest part of Signbee's proposition. It uses JSON over HTTP and explicitly recommends native language clients rather than a vendor SDK. Four operations cover send, markdown preview, status retrieval, and revocation. That small surface is not inherently better or worse than a larger API; it is efficient only when it exposes every state the buyer's workflow needs.
| Operation | Authentication | Documented behavior | Important boundary |
|---|---|---|---|
| POST /api/v1/send | Optional bearer key | Sends markdown or a PDF URL for two-party signing | Accepts one recipient |
| POST /api/v1/generate | Not required | Converts markdown to a PDF preview without signing | It is generation, not a signing transaction |
| GET /api/v1/documents/{id} | Bearer key required | Returns lifecycle status, signing URL, and PDF links | Tracking is polling-based in the reviewed docs |
| DELETE /api/v1/documents/{id} | Bearer key required | Revokes a document pending recipient signature | The documentation does not describe post-completion reversal |
The documented input contract is practical. Markdown supports common structural elements and removes a PDF-generation dependency from text-first automations. Existing PDFs must be reachable through a URL, so teams should confirm how source files are hosted, protected, fetched, and retained before sending sensitive material. The reviewed pages do not answer every privacy or data-location question that may follow from URL ingestion.
No-key mode is unusual and useful for evaluation: the caller provides sender identity details, and the sender verifies by email OTP before the recipient is contacted. Production automation is cleaner with an API key because the sender is pre-verified. The API key must still be treated as a signing-workflow credential, scoped and stored accordingly; Signbee's terms place responsibility for key security on the account holder.
MCP and AI-agent operability
Signbee publishes an npm package named signbee-mcp. Its first-party configuration runs the package through npx and passes SIGNBEE_API_KEY as an environment variable. The homepage and llms.txt list two tools: send_document for markdown and send_document_pdf for an existing PDF URL. The docs also describe a send_document tool more generally.
| MCP question | Documentation finding | What remains untested |
|---|---|---|
| Is a server published? | Yes; Signbee links npm and GitHub resources | Package installation and provenance were not audited |
| What can an agent do? | Send markdown or a PDF URL through the signing workflow | Tool schemas, validation, and returned errors were not exercised |
| How is it authenticated? | The documented configuration uses SIGNBEE_API_KEY | Credential handling across MCP clients was not tested |
| Does MCP prove reliability? | No; it proves a documented agent integration exists | Delivery, retries, idempotency, and uptime need live testing |
| Can the agent sign? | The workflow still includes sender verification and a recipient signing ceremony | Do not equate workflow operation with human signing authority |
Editorial conclusion: the MCP package is most valuable when it preserves the same narrow, understandable boundary as the REST API. An agent can prepare and send a request, while a person receives and completes the signing action. Buyers should test tool discovery, argument validation, duplicate-send behavior, cancellation, and error recovery before treating the package as production-ready.
Comparing agent-operated signing models?
See the direct SumoSign vs Signbee comparison for multi-party routing, branding, API, MCP, evidence, and price differences.
Compare SumoSign and SignbeeThe documented signing workflow, step by step
| Stage | With an API key | Without an API key | Evidence status |
|---|---|---|---|
| 1. Prepare | Caller supplies markdown or a PDF URL and one recipient | Caller also supplies sender name and email | Request shape verified in docs |
| 2. Verify sender | Sender is described as pre-verified | Sender receives an email OTP and completes setup | Vendor-described behavior; not tested |
| 3. Deliver | Recipient email is sent immediately after the request | Recipient email follows sender verification | Delivery speed and inbox placement not tested |
| 4. Sign | Recipient reviews the sender-signed document and signs | Same recipient ceremony after sender verification | Mobile clarity and consent not tested |
| 5. Complete | Both parties receive the completed PDF | Both parties receive the completed PDF | Certificate contents not independently inspected |
| 6. Retrieve | Authenticated status response exposes signed_pdf_url | API access requires an account key | URL lifetime and retention need confirmation |
The lifecycle names six states: draft, pending_sender, pending_recipient, signed, expired, and revoked. That is enough to model a simple ceremony. It does not expose partial progress among several recipients because the public request does not model several recipients. Teams should avoid simulating a multi-party agreement as unrelated two-party sends unless legal and operational owners accept separate documents, evidence records, and failure states.
Certificate, audit evidence, and legal claims
Signbee states that a completed document receives a SHA-256 signing certificate. Its terms say the service stores timestamps, IP addresses, and signature images, while other first-party materials describe party details, a document hash, and a verification URL. These are Signbee vendor claims because this review did not complete a transaction and inspect the resulting PDF or independently reproduce the hash.
| Evidence element | Signbee's published statement | What it can and cannot establish |
|---|---|---|
| SHA-256 document hash | Included with the completed certificate | Can support integrity checking; does not by itself prove identity or authority |
| Names and emails | Party details are recorded | Connects stated identities to the record; not high-assurance identity proofing |
| Timestamps | Signing times are recorded | Supports a chronology when system time and records are trustworthy |
| IP addresses | Stored as signing metadata | Provides context; does not uniquely identify a person |
| Signature images | Stored in the signing record | Shows the captured mark; intent and authority still depend on the ceremony and context |
| Verification URL | Described in first-party materials | May support later checking; availability and retention were not tested |
| Signed PDF URL | Returned after completion through the status endpoint | Supports software retrieval; expiry and long-term access need confirmation |
Signbee's terms identify its output as Simple Electronic Signatures and state that signatures are intended to be valid under the US ESIGN Act, EU eIDAS Regulation, and UK Electronic Communications Act. The same terms say Signbee does not guarantee acceptance by every court or regulatory body. This review treats the legal statements as vendor positioning, not accreditation, a legal opinion, or proof that every document type and jurisdiction is supported.
A buyer should evaluate signer intent, consent language, identity evidence, authority, delivery records, retention, document exclusions, and applicable law alongside the hash. If Advanced or Qualified Electronic Signatures are required, Signbee's own terms direct users to seek legal counsel; the product is not presented as QES.
Signbee pricing — retrieved July 18, 2026
The Free and Pro prices were consistent across the first-party pages reviewed. Business was not. Signbee's homepage, about page, Terms of Service, and llms.txt listed Business at $19 per month for unlimited documents. The live API documentation rate-limit table listed Business at $29 per month for unlimited documents. This unresolved $19/$29 discrepancy is material, so confirm the checkout amount, taxes, email limits, and applicable terms before buying.
| Plan | Published monthly price | Document allowance | Published email rate | Confidence |
|---|---|---|---|---|
| Free | $0 | 5 per month | 1 per minute in API docs | Consistent across reviewed pages |
| Pro | $9 | 100 per month | 10 per minute in API docs | Consistent across reviewed pages |
| Business | $19 or $29 | Unlimited | 30 per minute in API docs | Price unresolved across first-party sources |
The terms state that paid plans are billed monthly through Stripe and that cancellation takes effect at the end of the billing period. The documentation says monthly document limits reset on the first day of each month and returns HTTP 429 with Retry-After when a rate limit is reached. “Unlimited” should therefore be read alongside the documented email rate and acceptable-use terms rather than as unlimited instantaneous throughput.
| Monthly need | Likely documented tier | Nominal cost observation | Workflow caveat |
|---|---|---|---|
| Up to 5 documents | Free | $0 if the allowance and email rate fit | Still limited to the documented two-party flow |
| 25 documents | Pro | $9 per month | Effective cost depends on actual usage, not the 100-document ceiling |
| 100 documents | Pro | $9 per month | API docs publish a 10-email-per-minute rate |
| 500 documents | Business | $19 or $29 pending checkout confirmation | Confirm fair-use, delivery, and support expectations |
| 1,000 documents | Business | $19 or $29 pending checkout confirmation | Run volume and reliability testing before production reliance |
Security, privacy, and procurement questions
The terms provide useful baseline disclosures: B2bee Ltd operates the service, users are responsible for API-key security, paid billing runs through Stripe, a 99.9% uptime target is not guaranteed, and liability is limited under the agreement. An uptime target is not observed uptime, and this review found no independent operational data with which to assess reliability.
| Procurement question | What was found | Recommended buyer action |
|---|---|---|
| Data retention and deletion | Not sufficiently detailed on the reviewed product pages | Request lifecycle, backup, deletion, and certificate-retention terms |
| Data location and residency | Not established in the reviewed sources | Confirm hosting regions and transfer mechanisms |
| Subprocessors and DPA | Stripe is named for billing; a full list and DPA were not established | Request the current subprocessor list and data processing agreement |
| Incident response | Not detailed in the reviewed materials | Ask for notification commitments and security contacts |
| Service levels | Terms state a 99.9% target without a guarantee | Negotiate required remedies or choose a provider with an appropriate SLA |
| Independent certifications | No certification is asserted in this review | Require documentary evidence for any mandatory attestation |
| Email delivery | Signbee handles delivery; terms disclaim losses from failed delivery | Test real recipient domains, retries, and escalation paths |
| Sensitive document fit | Not determinable from API documentation alone | Complete legal, privacy, and security review before production use |
Signbee strengths
- A focused two-party workflow that is easy to understand from the public documentation.
- Markdown-to-PDF input removes a document-generation step for text-first agents and automations.
- A PDF URL path supports documents that already exist outside Signbee.
- No-key sender OTP creates a low-friction prototype path without pretending verification is unnecessary.
- Native HTTP avoids a mandatory SDK and makes the request portable across languages.
- Status retrieval and revocation cover the essential operational controls for pending documents.
- The published MCP package, Agent Skill, OpenAPI, and llms.txt offer several machine-integration paths.
- Five production documents per month at no cost is useful for genuinely low-volume workflows.
- The vendor is explicit that its signatures are SES rather than QES.
Signbee limitations and unknowns
- The documented send request has one recipient, so it does not cover multi-party routing or ordered approval chains.
- Reusable templates, signer roles, and visual field placement are not described in the reviewed documentation.
- Webhook delivery is not documented; the status workflow uses authenticated polling.
- Custom signing domains and detailed branding controls were not established from the reviewed pages.
- The actual signing page, mobile usability, emails, and completed certificate were not hands-on tested.
- Independent reliability, support responsiveness, and delivery data were not found.
- Data retention, residency, subprocessors, DPA availability, and incident commitments require direct confirmation.
- The live Business price conflicts between $19 and $29 per month.
- The terms target 99.9% uptime but explicitly do not guarantee it.
- The product is described as SES, not a QES or high-assurance identity service.
Who Signbee is best for
| Use case | Fit | Reason |
|---|---|---|
| Agent-generated mutual NDA for one recipient | Good | Markdown input and the two-party ceremony match the job |
| Founder sending a few simple agreements | Good | The free allowance and low setup reduce overhead |
| Developer embedding a basic signature send | Good | Native HTTP and a small documented lifecycle are straightforward |
| Agency contract with principal, client, and finance | Poor | The documented request does not model several coordinated signers |
| Repeated MSA with role-based fields | Poor to uncertain | Reusable templates and field workflows are not documented |
| Premium white-label client ceremony | Uncertain | Branding and custom-domain controls need vendor confirmation |
| Regulated process requiring QES | Poor | Signbee describes SES, not QES |
| Enterprise deployment with formal SLA and governance | Uncertain | Administration, certifications, procurement documents, and guarantees need review |
Signbee alternatives
| Alternative | Consider it when | Primary trade-off to evaluate |
|---|---|---|
| SumoSign | Agents must prepare, send, and track premium branded multi-party agreements while humans sign | A broader workflow and higher starting price than Signbee's simple sends |
| DocuSeal | Open-source or self-hosted deployment and template-first workflows matter | Operating responsibility and hosted-plan differences |
| BoldSign | Embedded signing, SDK breadth, and broader workflow features are priorities | Plan limits, API pricing, and required configuration |
| SignWell | A developer API and low-volume production use are the main requirements | Feature and allowance fit at the chosen tier |
| Dropbox Sign | A mature signature API and Dropbox ecosystem fit are valuable | Pricing and workflow complexity compared with Signbee |
| DocuSign | Enterprise governance, integrations, and organizational familiarity dominate | Cost, setup, and administrative weight |
| eID Easy or another QTSP | Qualified electronic signatures or regulated identity assurance are mandatory | Jurisdiction coverage, trust-service status, and ceremony complexity |
Alternative features and prices change frequently; the table identifies evaluation directions rather than claiming current plan parity. Start with the signing ceremony and evidence requirement, then compare live vendor documentation and contracts.
Final Signbee review verdict
Signbee deserves consideration on its actual merits: a clearly documented, inexpensive path from markdown or a PDF URL to a two-party signature. For an indie developer, lightweight automation, or agent sending a straightforward agreement to one recipient, that focus can be exactly right. There is no reason to buy multi-party routing, elaborate templates, or enterprise controls when the workflow never needs them.
The same focus sets the ceiling. A buyer should move beyond Signbee's documented model when one agreement needs several people, approval order, reusable signer roles, deep brand control, formal procurement commitments, or qualified signatures. Before production adoption, run a real API-key send and no-key OTP send, inspect the completed certificate, reproduce its hash, test recipient delivery, exercise MCP errors and duplicate requests, and get written answers to the privacy and pricing questions above.
Need premium multi-party signing instead?
SumoSign lets agents prepare, send, and track branded agreements through API or MCP while each authorized human signs their own part of the workflow.
Explore SumoSign pricingFrequently asked questions
What is Signbee?
Signbee is an API-first e-signature service operated by B2bee Ltd. Its documented workflow accepts markdown or a PDF URL, verifies a sender, emails one recipient for signature, and provides a completed PDF. It also publishes an MCP server, Agent Skill, OpenAPI specification, and llms.txt.
Is this a hands-on Signbee review?
No. This is a documentation-based review using Signbee's first-party pages retrieved on July 18, 2026. No live send, signing ceremony, email delivery, MCP execution, support interaction, reliability measurement, or certificate inspection was performed.
Is Signbee free?
Signbee's live first-party pages listed a Free plan with five documents per month and no credit card requirement on July 18, 2026. The API docs also listed an email rate of one per minute. Confirm the current allowance in the dashboard before relying on it.
How much does Signbee cost?
Free was listed at $0 for five documents per month, and Pro at $9 per month for 100 documents. Business had an unresolved conflict: the homepage, about page, terms, and llms.txt showed $19 per month, while the API docs showed $29. Both called the document allowance unlimited.
Why do Signbee's Business prices differ?
The public first-party sources were inconsistent when retrieved. This review cannot determine whether the $29 documentation row is stale, anticipatory, or applies differently from the $19 product and terms price. Confirm the amount and terms at checkout or ask Signbee in writing.
Does Signbee support multiple signers?
The public API documentation reviewed describes two-party signing with one sender and one recipient. The send request accepts one recipient, and the lifecycle tracks sender then recipient. Ask Signbee directly if a newer multi-signer workflow has launched after July 18, 2026.
Does Signbee have an MCP server?
Yes. Signbee publishes signbee-mcp and documents an npx configuration using SIGNBEE_API_KEY. Its first-party materials list tools for sending markdown and PDF URLs. The package was not installed or execution-tested for this review.
Can Signbee accept an existing PDF?
Yes. The send endpoint accepts pdf_url as an alternative to markdown. The PDF must be available through a URL, so buyers handling sensitive documents should confirm fetch behavior, access controls, retention, and exposure risks.
Does Signbee provide an audit trail?
Signbee states that completed documents include a SHA-256 certificate and that signing metadata includes timestamps, IP addresses, and signature images; other first-party pages also mention party details, a hash, and a verification URL. Those claims were not independently checked against a completed artifact in this review.
Are Signbee signatures legally binding?
Signbee says its Simple Electronic Signatures are intended to be valid under named US, EU, and UK laws, but its terms do not guarantee acceptance by every court or regulator. Enforceability depends on the document, intent, authority, identity evidence, ceremony, jurisdiction, and applicable exclusions. Obtain legal advice for the specific transaction.
Does Signbee support QES?
Signbee's terms describe Simple Electronic Signatures, not Qualified Electronic Signatures. If QES is mandatory, evaluate a qualified trust service provider with the required jurisdictional status.
Can Signbee be self-hosted?
Self-hosting is not offered in the public product materials reviewed for this article. That is a documentation finding, not a claim about private arrangements. Buyers requiring source control or on-premises deployment should ask Signbee or evaluate a self-hostable alternative.
What are the best Signbee alternatives?
Consider SumoSign for branded multi-party agent workflows, DocuSeal for open-source or self-hosted needs, BoldSign or Dropbox Sign for broader API surfaces, DocuSign for enterprise breadth, and a qualified trust service provider when QES is required. The best choice follows the signing ceremony and evidence requirement, not the endpoint count.
