For developers.
The SDT Engine is the box of Lego blocks. The API is how you take them out of the box. Every product in the Built on SDT catalog runs on this same Engine. Yours can too.
Secure Digital Transport (SDT) is the category. The SDT Engine is the patented technology that makes the category real. It moves sensitive data in and out of any system without asking the recipient to create an account, remember a password, or log in to a portal.
SDT eliminates the credential as a precondition for secure data exchange. The recipient gets one notification. They click. The data moves. There is no login screen because there is no login. That single architectural choice is what makes the rest of the math work. Less attack surface for Security. Less friction for Operations. Less compute for Tech.
Every product Botdoc has ever shipped, and every Third Party Integration (TPI) anyone has built on top of us, runs on the SDT Engine. SecureMFP for banks. The automotive stack at dealers nationwide. Cloud Maven's Salesforce app. Edward Jones' Secure Document Exchange. Same Engine, different builds.
Think of it in Lego terms. The SDT Engine is the box of Lego blocks. The API is how you take them out of the box. EAPs are pre-built kits we sell ready to fly. TPIs are when we help you write the build instructions for what you want to ship on top.
The category. Secure Digital Transport. The new way to move sensitive data without anyone logging in.
Our technology. Patented. Built over a decade. The infrastructure that makes SDT real.
How developers connect. JSON, JWT, REST.
What gets built. Products by Botdoc (EAPs) and by third parties (TPIs).
The SDT Engine is not a wrapper around someone else's secure file portal. It is not a feature layer bolted onto email. It is the underlying mechanism, protected by patents granted in six jurisdictions across North America, Europe, Asia-Pacific, and the EU.
The patents cover the core architectural move. A recipient can receive or return sensitive data through an authenticated, encrypted, audited transport without first establishing an identity inside our system. No account. No credential. No portal session. That mechanism is what eliminates the most-attacked surface in secure file exchange. It is also why every competitor in the legacy "secure email" or "secure file transfer" category cannot copy what we do without engineering around a published patent claim.
For developers, this means two things. One, the technology you are building on is defensible. Two, the architecture you ship is materially different from anything an OpenSSL plus SFTP stack can produce.
United States patents include Nos. 10,469,463 and 10,999,259. Australia Patent No. 2014338913. India application filed.
Three layers of capability. Transport methods to move data. Delivery channels to notify the recipient. A customization layer to make the experience feel like yours, not ours.
Send sensitive data to a recipient. One outbound leg. They click the notification and the payload is delivered, no login required.
Request sensitive data from a recipient. Two legs. Outbound notification asking for the data, inbound delivery once they upload it. Same no-login experience on their end.
A session that wraps multiple secure interactions in one recipient experience. Orchestrate push, pull, signing, payment, and ID capture inside a single container instead of stitching together separate transactions.
The same push and pull primitives, scoped inside a P2 container so they share session state, audit context, and the recipient's view.
Document signing inside the secure session. Integrates with DocuSign templates so you can keep your existing signing artifacts and contracts.
Collect payment inside the same secure recipient session. Available. Call for scope.
Capture government-issued ID images inside the container, with the same no-login flow the recipient already trusts.
Verify the captured ID matches the recipient. Stops at the session boundary, so the verified result is available to your systems through the same callback you already configured.
The default notification channel. Recipient gets an email, clicks once, and the secure session opens.
Twilio-powered, with US local and toll-free options. For audiences who live in their text app, not their inbox.
Send from a 5 to 6 digit short code for higher deliverability and brand trust on SMS. Call for scope.
Your own dedicated short code. Reserved to your brand, not shared with any other sender. Call for scope.
Emails appear as your domain instead of @botdoc.io. The recipient sees a sender they already recognize, which materially lifts open rates.
Every page the recipient sees can be CSS-customized to match your brand. Logos, colors, type, layout. The recipient never sees Botdoc unless you want them to.
Fully HTML-customizable email templates with merge tags like first name and message body. Build the notification once and let the Engine populate it for every send.
Recipient URLs come from your own subdomain, like docs.yourcompany.com instead of dev.botdoc.io. The link the recipient clicks already looks like you.
Full audit log of every transaction. Useful for regulators. Required for FFIEC, GLBA, HIPAA, FERPA, and most state privacy frameworks.
Choose your webhook payload shape. Flat for systems that want a simple key-value object. Nested for systems that want structured detail.
Publicly-signed certificate validation on your endpoint so the callbacks your systems accept are provably from us, not from someone replaying a captured payload.
Three steps from zero to a working secure transaction. No sales call required to explore. The sandbox is open. The keys are free. If you want a human, we are on Slack.
Trade your API key for a JSON Web Token (JWT). One request. Use the token on every subsequent call.
Create a container, define the recipient, send the notification. You can do this end to end in under five minutes with the Postman collection.
When the recipient completes the interaction, your callback URL gets the payload. Flat or nested, your choice. That is the loop.
You also get:
The same Engine the sandbox runs on is the Engine that processes regulated financial, automotive, and government transactions every day. Production-grade by default, not as an upgrade tier.
Industry standard, token-based auth. No bespoke key formats, no hand-rolled HMAC scheme. Your security review team has seen this before.
Every send, every receive, every callback. Time-stamped, queryable, exportable. Built for the regulator visit you do not want to dread.
On the dashboard. Your admin console is protected by the same control regulators expect on any system that touches sensitive data.
From sandbox to mission-critical production. Pick the tier that matches your reliability target. Call for scope.
Publicly-signed cert validation so your endpoint can prove the inbound payload is ours. Optional, recommended, free.
The architectural choice the patents protect. Eliminates the credential as an attack surface, which is the surface most often compromised in regulated industries.
Every product in our catalog and every partner build in the wild runs on this same Engine. You are not the first to ship on it. You will not be the last.
SecureMFP for banks. The Botdoc automotive stack at dealers nationwide. Botdoc Spark for SMB self-serve. Cloud Maven's Secure File Transport for Salesforce. Edward Jones' Secure Document Exchange. Different products, different verticals, one Engine underneath.
Every product on the Built on SDT page runs on this same API. Yours could be next.
If you want to explore, the sandbox is open. If you want a custom build scoped end to end, we will get on a call. Either way, the path starts here.
Questions? Join us on Slack: botdoc.io/slack