# sms.created: Clerk sent a text
Fires when Clerk creates an outbound SMS, overwhelmingly verification and sign-in codes. Like email.created, it records the sending, not the outcome.
## What to do on receipt
1. Log it: recipient phone number (as much as your retention policy allows), timestamp, message type. This is your "we sent the code" evidence for support.
2. Do NOT mark the phone number verified. There is no `sms.verified` event in Clerk's catalog. Phone verification status lives on the user's `phone_numbers` entries and arrives via `user.updated`.
3. Watch for anomalies in aggregate: a sudden spike in sms.created for one user or one number range can indicate SMS pumping abuse. Alert on rate, not on single events.
4. Return 200.
## The trap
Waiting for a verification event that does not exist. Agents sometimes subscribe to sms.created expecting a verification callback, then build polling loops or mark numbers verified on send. The verification signal is `user.updated` with the phone number's verification status flipped.
## Checklist
- Audit the full communication event list in the Dashboard Event Catalog before assuming an event exists. email.created and sms.created are the complete set.
- SMS costs money per message. A handler that triggers additional SMS sends off sms.created can create a send loop; never send SMS from this handler.
- Keep PII minimal in logs. Phone numbers in plaintext logs are a liability; hash or truncate per your policy.