Confirm
A code to the destination on file. If it returns, the channel is reachable. Bloom keeps an irreversible hash of that proof, not the contact itself.
Bloom Identity is a minimal layer. We confirm that the person enrolling controls the phone number or email on file, then we deliver the code with retries and alternate routing. We do not keep your users or raw contacts, only an irreversible proof that a channel was confirmed.
Learn more/ About
The application already has the user, the email, and the phone. Bloom sits behind that experience as two things: a short-lived check that the destination on file is real, and a delivery layer that keeps trying until the message has a path.
If a code comes back, someone at that inbox or handset can receive communications there. After that, the product talks: a sign-in, a password change, a delivery, a security alert. If a carrier, inbox, or route fails, Bloom retries and, when needed, sends by another path. SMS, RCS, and email are those paths.
A code to the destination on file. If it returns, the channel is reachable. Bloom keeps an irreversible hash of that proof, not the contact itself.
Retries and alternate routing so a verification code or transactional notice still arrives when the first hop fails.
The application still owns the account and the reason a message goes out. Bloom stays the layer underneath.
/ Services
A one-time code to the email or phone on the account. Entering it proves the user can receive communications there.
Retry methods and alternate routing so a code or notice still reaches the inbox or handset when the first path does not.
Confirmations and alerts for an enrollment or account the user already started.
Codes and notices to the number on file, including rich messaging when the device and carrier allow it.
The same class of transactional content when mail is the path the product chose.
/ Uses
A short-lived code confirms the person at the keyboard can receive traffic at the phone or email already on the account, before the session continues.
Before a shopper joins a rewards program, a code confirms the phone or email they entered is one they control.
Before a bank account is linked for payments, a code confirms the person setting it up controls the phone or email on the account. These messages stay operational, not promotional.
Unusual activity on the account can be described to the inbox or number already on file, after that channel has been shown to work.
/ Flow
The application already has an email or mobile number on the account.
A verification code is delivered to that inbox or handset over SMS, RCS, or email.
The user returns the code. The application knows the channel is reachable.
Later notices use the same pipes. If a hop fails, Bloom retries and can route by another channel.
/ Channels
A product can use more than one path. A code might go to SMS while a longer notice goes to email. RCS is available when the device and carrier support rich business messaging. If a path fails, Bloom retries, then can send by another of those routes.
Text messages for verification codes and transactional notices when the product needs to reach a phone number on the account. Short, timely, and tied to an action the user already took.
PrivacyThe same class of transactional content, delivered as rich business messaging when the device and carrier support it. If RCS is not available, traffic can fall back to SMS or email.
TermsCodes and operational notices to the address on file. Useful when the update needs more room than a short text.
ContactShort-lived passcodes to the email or phone on the account, used as the extra factor before the product treats that channel as proven.
Services/ Contact
Questions about verification, delivery, or how retries and routing would sit behind an application can go to support.