Did the SMS arrive, how fast, and with what content?
An OTP that takes 90 seconds on one operator instead of 5 means lost sign-ups — while your SMS provider reports "delivered". Accuse triggers the journey, waits for the SMS on a real French SIM and measures the delay to the second, checks the content, and alerts when nothing arrives.
No credit card to start. Secure payment through Stripe when you change plan.
The delay, to the second
Where each operator sits — and why this is empty
An OTP that takes 90 seconds on one operator instead of 5 means lost sign-ups, while the provider reports “delivered”. This chart is the screen that must show it. It is empty, and it will stay empty until the fleet has a phone with a SIM: no SMS has ever been received, so no delay has ever been measured.
measurement slots (empty)
p50 = median
p95 = distribution tail
One nuance matters: the SIM operator is not published by the job result. Accuse therefore records the one declared by the scenario. Per-operator latency is exact by scenario construction, not verified by the network — and no figure will be published before it is.
Questions
Frequently asked questions
Has a real SMS ever been received?
No. The fleet holds no phone with a SIM, so no real SMS has ever been received, no operator delay has been measured, and the `sms-wait` job has never run for real. The "SMS received on 2 operators" criterion is still unmet today.
What happens to my SMS content?
It is encrypted (AES-256-GCM, unique nonce, mandatory key) and kept for 30 days. Off-pattern, it is destroyed without being stored: neither plaintext nor ciphertext touches the database; only an audit log without content keeps a trace. No API response carries an SMS body.
Can I read other SMS received by the SIM?
No, never. The customer only sees SMS from their own declared senders, and there is no free inbox. That is a safeguard, not a commercial option: the service cannot be used to create fake accounts elsewhere.
Is the displayed operator the one on the SIM?
Not proven by measurement: the job result does not publish the SIM operator, so Accuse records the one declared by the scenario. Per-operator latency is exact by scenario construction, not verified by the network.
How do you prove the sender belongs to me?
In phase 1, proof of ownership (a file on the domain, or a Play developer account matching the package) is checked by hand, with a written procedure. Automating it is planned, not done.
What it does
Concretely
Delay measured to the second
Network timestamp and receive timestamp give the real delay, not a provider average. The dashboard shows median and p95 delay per operator, and the non-delivery rate.
Content is checked, not just received
The code is extracted with the scenario pattern, the displayed sender is checked, and the encoding is analysed: GSM-7 or UCS-2, accents, segmentation into parts, length. An SMS that arrives broken is not a success.
Content is encrypted, and destroyed when off-pattern
The stored body is encrypted with AES-256-GCM under a mandatory per-environment key, and purged after 30 days. An SMS that matches no declared sender is destroyed without being stored: neither plaintext nor ciphertext touches the database.
The customer only sees their own senders
No free inbox: no route lists the SMS of a SIM, and no API response carries an SMS body. An audit log keeps the sender, length, fingerprint and decision, never the content.
Four ways to trigger the send
By API (Accuse calls a customer endpoint), by mobile journey (a Maestro flow types the number), by web journey, or manually. The reference path stays the API: its measurement window is the most reliable.
What happens to the content
Encrypted, then destroyed when off-pattern
A service that receives SMS must say what it does with them. Here it is, in order: the content is encrypted, kept for 30 days, and destroyed before any write when it does not match what the customer declared. No API response carries an SMS body.
1
SMS received on the SIM
The SMS arrives on a real French line. Nothing is written at this stage.
2
Declared sender?
If the sender is not among those declared by the customer, the decision is no: the content never touches the database.
3
AES-256-GCM encrypted
Mandatory per-environment key, unique nonce. Without the key the product refuses to start: there is no default value.
4
Kept 30 days
Then automatic purge. Only the audit log remains: sender, length, SHA-256 fingerprint and decision — never the content.
Off-pattern: destroyed
Undeclared sender, unmatched pattern, disabled scenario, suspended customer or reached cap: the content is neither stored in clear nor stored encrypted. There is no free inbox, and no route lists the SMS received by a SIM.
AES-256-GCM, unique nonce
Mandatory key: no fallback
30-day retention
No SMS body in any API response
Audit without content (SHA-256 fingerprint)
In all honesty
What we do not do
A product that hides its limits wastes everybody's time. Here are ours, today.
No real SMS has ever been received: the fleet holds no phone with a SIM, and the `sms-wait` job has never run for real.
No device exposes the `sms` capability: the selector requires it, so a real run stays queued.
The SIM operator is not published by the result: it is declared by the scenario, so per-operator latency is not proven by measurement.
Proof of sender ownership is manual in phase 1, not automated.
Alerts have never actually been delivered: no channel is configured, so the kit logs the intent instead of sending.
The probe app’s default-SMS-app role must be validated model by model, and a mobile journey can miss an SMS received during the journey.
Accuse only receives: it does not send SMS, does not rent numbers, and has no headless web trigger.
No payment in phase 1: plans are listed, Stripe is not open.
Try it on a real phone
Create an account, take a key, run your first test. It is free to start.