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, one underlying technology that scales across every regulated vertical we serve.
Think of it in Lego terms. The SDT Engine sits in the middle of a four-layer stack that runs from category framing at the top down to specific shipped products at the bottom. Each layer has a distinct role and a distinct audience.
The SDT Engine is the box of Lego blocks. The API is how you take them out of the box. External Application Projects (EAPs) are pre-built kits we sell ready to fly. Third-Party Integrations (TPIs) are when we help you write the build instructions for what you want to ship on top. Buyers, developers, partners, and OEMs each enter the stack at a different layer depending on what they want from SDT.
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, and Asia-Pacific.
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 Patent Nos. 10,469,463 and 10,999,259. Japanese Patent No. 6978498. Australian Standard Patent No. 2017338913. Indian Patent No. 535215. European Patent No. 3510745. Canadian Patent No. 3,038,119.
Four core primitives cover the foundational data-movement patterns. PUSH and PULL handle one-direction transactions. The P2 Secure Container wraps multiple interactions in one recipient session. P2 PUSH and P2 PULL scope the core primitives inside that session for shared state and audit context.
Send sensitive data to a recipient. One outbound leg. They click the notification and the payload is delivered, no login required.
Learn more →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.
Learn more →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.
Learn more →The same push and pull primitives, scoped inside a P2 container so they share session state, audit context, and the recipient's view.
Learn more →Six P2 session enrichments extend the secure container with workflow-specific capabilities the core primitives do not provide on their own. Signing brings document signature inside the container with DocuSign template integration. Payment collection accepts payment inside the same session. ID capture grabs a government-issued ID image. ID Verification confirms the captured ID matches the recipient at the session boundary. Credit Pull retrieves credit data through pre-built bureau integrations. Credit Application captures a credit app inside the session and routes it to the dealership's decisioning provider.
Document signing inside the secure session. Integrates with DocuSign templates so you can keep your existing signing artifacts and contracts.
Learn more →Collect payment inside the same secure recipient session. Available. Call for scope.
Learn more →Capture government-issued ID images inside the container, with the same no-login flow the recipient already trusts.
Learn more →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.
Learn more →Soft and hard credit pulls inside the secure session through pre-built bureau integrations (currently 700Credit). The pulled credit data routes through the same callback your systems already consume, with the same audit trail as the rest of the deal.
Capture a credit application inside the same recipient session and route it to your decisioning provider (currently NCC Direct). The applicant fills out the form once, no separate vendor portal, no re-keying on the dealership side.
The security-primitive layer is where new patentable architectural moves get added to the SDT Engine without disrupting any existing customer integration or any product already shipped on the Engine. The current entry on this layer is Reverse Authentication, which flips the historical sender-recipient trust direction. The recipient verifies the sender, not the other way around. That single architectural inversion is the answer to the gap that Business Email Compromise (BEC) attacks ride on. Reverse Authentication is patent-pending, ships behind a feature flag on the same API your developers already integrated, and integrates with every transport primitive in the stack above it.
The delivery-channel layer is how recipients get notified that something is waiting for them. Email is the default. SMS is the alternative for audiences who live in their text app. Short codes lift deliverability and brand trust on SMS specifically. Custom SMTP makes the email come from your domain instead of a Botdoc domain, which materially lifts open rates. Five delivery options, mix and match per workflow.
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.
The customization layer makes the SDT Engine feel like your product to your recipient instead of feeling like Botdoc. White-label CSS, custom email templates, custom subdomain on the recipient URL, full audit trails for compliance, and secure callbacks complete the picture.
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, talk to the Dev team.
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 closes the scan-to-email gap for banks and credit unions. The Botdoc automotive stack (Connect, Lite, ID Verify) runs at dealers nationwide and is privately labeled by KPA as Secure Messaging inside the Vera Suite compliance platform. Botdoc Spark is the SMB self-serve product launching Q3 2026. Cloud Maven's Secure File Transport for Salesforce ships on the AppExchange. Edward Jones uses the Engine for Secure Document Exchange. VedaPointe.Send runs on it inside EPIC. Different products, different verticals, one Engine underneath, one set of patents protecting the architecture across every build.
Every product on the Built on SDT page runs on this same API. Yours could be next.
There are two paths into the SDT Engine, and they fit different builder profiles. Developers who want to evaluate the technology hands-on start in the sandbox: free keys, public documentation, no sales call required to make the first secure transaction work end to end. Product leaders or executives scoping a vertical External Application Project or a Third-Party Integration on top of SDT skip the sandbox and book a working session with the team. The working session covers your use case, the specific transport primitives you would need, the customization layer required to ship under your brand, and a rough timeline and commercial frame. Either path produces a concrete next step in the same conversation, whether the next step is a working sandbox transaction or a fully scoped build plan.