01 — YOUR QUESTIONThe one-device binding, and why your app sits outside it
“The Client API binds one device/machine per account. How does a third-party app become an additional authorized device… without displacing their extension or phone, and without holding their password?”
Short answer: it doesn't become a device at all — and that's deliberate. You guessed the shape correctly with approve-on-existing-device / delegation.
A Blasts account has exactly one bound approval device — the customer's phone. That binding is the entire security story: an approval is valid only if it carries a signature from that device's private key, which never leaves the phone. If a third-party app could become an additional bound device, that guarantee would be worth considerably less.
So partner apps don't compete for that slot. They receive a delegated, scoped credential instead.
Think of the phone as the customer's signature. Partners never get a copy of the signature — they get a signed permission slip that says “this business may ask me to approve things,” and the customer can tear it up at any time.
02 — ARCHITECTUREThe scoped-identity model Ratified 8.20.26
An SDK instance receives a credential scoped to (account, organization) — never to the account as a whole.
- The SDK generates an ECDSA P-256 keypair on the device at enrollment. The private key stays in the Keychain / Keystore and never transits the network.
- That key registers against the tuple
(customer account, your org_id). - Assertions signed by it carry an
audclaim bound to your organization. Our server rejects any assertion whoseauddoesn't match the relying party presenting it. - The customer's phone remains the sole approval authority for the account itself — recovery, and adding or removing partners.
What that produces
| Scenario | Result |
|---|---|
| Your app enrolls | Nothing on the account is displaced. No rebind, no session kicked, no inbox rekey. |
| Customer runs five partner apps | All five hold live credentials simultaneously. None conflicts with another. |
| Your credential is stolen | It can produce assertions for your aud only. It cannot approve a login at another partner, and cannot authorize account-level changes. |
| Customer revokes you | Only your credential dies. Every other partner, and the customer's own devices, are untouched. |
This generalizes a pattern already running in production — our dispatch-box pairing, where a paired phone carries a box credential without becoming the account device. We're extending proven machinery, not inventing new cryptography.
You will never have to explain to a customer why installing your app signed them out of something else. In this design, that failure mode does not exist.
03 — AVAILABLE NOWLoginBlasts as a relying party In production
If what you want first is “let my users sign in with a Blasts approval,” that API exists today. Server-to-server. No SDK required, nothing installed on the customer's machine.
Provisioning, once: we issue a partner API key plus a signing secret. Requests carry a Bearer key and an HMAC signature. Your partner record must be flagged login_enabled.
/connect returns a uniform invited response whether or not that email corresponds to a Blasts account. Our API cannot be used to enumerate our user base. That is intentional.
Hardening you inherit
- Approval requests expire after five minutes.
- A denial triggers a 15-minute cooldown on request creation.
- A ceiling of roughly three pending requests per user, per RP, per five minutes — past that isn't flaky login, it's an attack, and it's treated as one.
- Easier methods (one-tap, pick-the-match) require an additional ACK ceremony to enable per-organization. The safe method is the default.
- Step-up is enforced inside the device-rebind window.
On passwords
There is nothing to hold. Blasts accounts have no passwords. Authentication is email codes plus device-key signatures. Your application holds only its own API credentials and receives approved / denied verdicts. You never see, store, or transmit a customer credential.
On “multiple devices at once”
Many surfaces can hold live sessions on a single account — the browser extension, the phone, and any number of connected partners. There is exactly one bound approval device. Everything else authenticates alongside it, never instead of it. That is why nothing gets displaced.
This whole lane is runnable today: the sample app is the complete relying-party flow in one dependency-free Node file, and the support & versioning policy states what we promise integrators about upgrades and deprecations.
04 — IN BUILDBlastsKit, the embedded SDK In build
A drop-in library for iOS, Android, and Web that gives a partner's app both capabilities for their own customers: phone-approved sign-in, and messages delivered straight to the screen.
Enrollment is one call
The SDK generates its keypair, calls /api/org/auto-connect with your org_id, and the customer sees a single explicit consent moment: “Get alerts and sign-in approvals from [Your Company] — Allow / Not now.”
That consent moment cannot be buried in a Terms-of-Service checkbox. Our entire product claim is consent-gated delivery; enrollment-by-ToS would contradict it everywhere else and hand any customer's counsel an easy objection. The friction we remove is codes and copying — never the decision itself.
Delivery
Message bodies are end-to-end encrypted. Push notifications carry a contentless doorbell — the payload is fetched and decrypted on-device. For alerts to ring inside your app rather than ours, your push credentials (your APNs key, your FCM service account) register against your organization and we send through yours. That registry is part of this build.
The alert appears on the customer's phone screen the moment it's sent. No email, no SMS fee, no inbox to fight through. The content is encrypted in transit — including from us.
Scope for version one
One rail: organization to customer. Alerts, notifications, and deal blasts all travel it. Deliberately not in v1 is peer-to-peer messaging between end users inside partner apps — that pulls an entire social surface into scope and would delay everything else by months. If demand warrants it, it's a later addition rather than a v1 compromise.
05 — COMMERCIALWhere deals fit
A deal is just a blast. Your organization sends one, the customer taps it, and they land on the Savings Sites zone checkout — where the transaction already happens today.
- No commerce code in your app. No cart, no payment surface, no PCI exposure. You carry the message; we handle the money.
- No deals UI to build or maintain. The tap opens a page we operate and keep current.
Every partner app that embeds BlastsKit becomes another channel through which local deals reach real customers — without recruiting those customers one at a time.
The partner's existing user base becomes reachable, with explicit consent, on a rail that costs nothing per message.
The model for a partner developer is straightforward: you buy Blasts Credits to send, your customers receive alerts they genuinely opted into, and when those alerts carry local offers, the transaction settles on our side.
06 — STATUSWhere things actually stand
I'd rather you plan against reality than a roadmap.
Shipped and running
- LoginBlasts relying-party API — the three endpoints above, in production
- Organization tenancy and delegation controls
- Device pairing with end-to-end encrypted key exchange
- Encrypted inbox delivery and approval ceremonies
- A working reference phone application — proof the full client path works end to end
BlastsKit
/api/org/auto-connect— one-call enrollment- Per-organization push credential registry, so alerts ring in your app
- The SDK packages — largely extraction of what our phone app already does into distributable libraries
- Developer surface — sandbox organization, quickstart, sample app, versioning policy
Decided and locked (August 20, 2026): the scoped-identity model and the v1 scope described above. Those were the two decisions gating everything downstream, and they're closed.
I'm not going to quote a date I'd have to walk back. What I will say is that the cryptographic and server work is the part that's done — what remains is packaging, credential plumbing, and developer experience. When there's a sandbox to build against, you'll have it before anyone else. You asked the question that shaped the design, and that earns first look.
On the patents
Three provisional applications are on file — 64/082,178, 64/119,378, and 64/119,849 — covering hardware-gated consent, consent-gated end-to-end encrypted authentication, and configurable multi-method authentication. We can discuss the architecture openly.
If you want to start now
Take the relying-party API. It's real, it's documented, and integrating it means that when BlastsKit lands you're already provisioned and already fluent in our auth model.
Al Inga
TIPS Marketing Services Corp