Read the headline for the claim and the second half of the card for how it is held up. If the second half were removed, the card would come off the page.
01
Everyone here is a licensed agent
An agent account cannot start a plan or a trial, invite a client, send a tour out or send a buyer agreement until the license behind it is verified. Before that, the account can browse, finish its profile and build a tour in draft.
How it is enforced
One shared verification check sits in front of those actions. If the account is not verified, the action stops with a Verification Pending message instead of going through. Verification happens one of two ways: the license number is matched against the MLS agent record, with the agent's own name cross-checked against the name on that record, or an admin approves the account by hand.
The check runs in the app, at each of those buttons, and for the three that leave the product (sending a tour, inviting a client, sending a buyer agreement), the API refuses an unverified caller as well. Starting a plan is a product gate only. One outbound action sits outside both today: inviting another agent to a team is not verification-gated.
02
Consent, logged
Turning text messages on, and turning them off again, both leave a record. Neither is a silent state change.
How it is enforced
Every flip of an SMS switch (the master control and each individual category) writes a consent row before the preference itself is saved. The row carries who changed it, the channel, whether it was an opt-in or an opt-out, where in the product the change was made, and the time it was written. Turning SMS on when every category was off also stamps a consent date on the account.
Of the four notification categories, Updates & news is the one whose push channel ships switched off. You turn that one on; you do not have to find it and turn it off.
03
Preferences that stop the message
A push category switched off is not filtered out on your phone. The check runs on the server, and it decides whether the push is handed to the delivery service at all.
How it is enforced
The send function reads the recipient's stored preferences server-side, maps the notification type to its category, and only queues a push when that category is on and the device has a token. Everything else is recorded as skipped, with the reason.
Two limits worth stating. The preference governs the push to your device, not the record: the item still appears in your in-app notification list. And the check is not even across the channels. Every push category runs through it. Email runs through it for saved-search alerts and for marketing, and for nothing else. A showing request emailed or texted to a listing agent about a specific property is not preference-gated at all.
04
One person cannot notify a stranger
A notification the app sends as you can only reach people you already have a relationship with in the product.
How it is enforced
A send started by a user is checked against a list assembled at that moment: their own account, their agent, an agent's own clients, the participants of the specific tour in question, and the agents on their teams. A recipient outside that list is dropped and counted, not delivered.
One path sits outside that list on purpose. Sending a tour out is the server notifying each listing agent, not the app notifying them as you, and if the email on the MLS record belongs to an account here, that agent gets the showing request in the app as well as by email. Reaching a listing agent you have never met is what a showing request is for.
05
Signature evidence, without keeping the address
A signed buyer agreement records who signed, when, and from what; and the signer's IP address is not part of what is kept.
How it is enforced
At the moment of signing, the address is reduced to a one-way SHA-256 hash and only the hash is stored. Two records can be compared; neither can be turned back into an address. Stored beside it: the signing timestamp, the browser or app identifier, and device details.
In-app signing is an add-on rather than part of the entry tier, and the add-on is not separately priced yet.
06
A full event log per agreement
The history of an agreement is not reconstructed from the document. It is written down as it happens.
How it is enforced
Each agreement accumulates its own event rows (draft created, sent, field values submitted, signed, partially signed, fully signed, voided) with the actor and the time on each. The finished PDF also carries its own Signing Certificate page: the agreement id, the completion time in UTC, and each signer by name with their signing status.
07
Support cannot spend your money
When support opens your account to reproduce a problem you reported, the two controls that move money are closed to them.
How it is enforced
Starting a checkout and opening the billing portal both test for an active support session first and refuse, with the message naming whose account it is. The checkout refusal points support at an internal tool that grants a subscription on the record instead: a different action, taken as themselves.
The block was already in the code before billing ever went live, rather than planned for later.
08
You cannot quietly cancel on a listing agent
Deleting a tour that other people have already committed to is not a silent operation, and the system will not let it become one.
How it is enforced
A tour carrying a confirmed showing, a confirmed client or recorded feedback takes the strict path: you type DELETE to confirm, and the cancellation notices are sent before anything is removed. If that step does not come back successful, the tour is not deleted and you are told to try again.
The notices go to the listing agent on each committed stop and to the clients on the tour, by email, with an in-app notification to the clients as well. What blocks the delete is the notification step itself failing; a single address that bounces is recorded rather than surfaced to you.
09
Delivery you can have checked
The messages the product sends on your behalf are written down with their exact body, not a summary of it, and not only the ones that worked.
How it is enforced
Every email goes out through one shared sender that writes a row either way, and the showing-request texts and the push notifications write the same row. Each row holds the channel, the recipient, the subject, the exact body text, which function sent it, and whether it was sent, failed or was skipped, with the provider's message id where there is one and the error text where there is not. Rows are indexed by recipient, channel, type and time.
That archive is a support tool, not a report in your account. It covers product messages; the one-time codes the login system texts you are not in it. It means a question about a specific message has an answer on file rather than a guess.
10
Your buyer is not named in the showing request
The showing request a listing agent receives identifies you. It does not identify your client.
How it is enforced
The request is built from the buyer agent's name, brokerage and contact details plus the property, the requested time and a link to answer. There is no client-name field in the template to fill in, by email or by text.
More detail on the notification layer specifically (the four categories, the three channels and what your phone's own settings override) is on the notifications page.
