Prove the channel. Get the message there.

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 layer behind the product.

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.

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.

Deliver

Retries and alternate routing so a verification code or transactional notice still arrives when the first hop fails.

Then the product

The application still owns the account and the reason a message goes out. Bloom stays the layer underneath.

/ Uses

Where the check shows up.

New sign-in

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.

Loyalty enrollment

Before a shopper joins a rewards program, a code confirms the phone or email they entered is one they control.

Payment setup

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.

Security notices

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

From a contact on file to a message that arrives.

On file

The application already has an email or mobile number on the account.

Check

A verification code is delivered to that inbox or handset over SMS, RCS, or email.

Confirm

The user returns the code. The application knows the channel is reachable.

Arrive

Later notices use the same pipes. If a hop fails, Bloom retries and can route by another channel.

/ Channels

How a code, or a notice, can travel.

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.

SMS

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.

Privacy

RCS

The 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.

Terms

Email

Codes and operational notices to the address on file. Useful when the update needs more room than a short text.

Contact

One-time codes

Short-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

Plug Bloom in behind a product.

Questions about verification, delivery, or how retries and routing would sit behind an application can go to support.

Email support