# session.created: the sign-in signal
Fires when a user completes sign-in and Clerk creates a session. Use it for sign-in audit trails, new-device notifications, and first-touch onboarding. Do not use it as activity tracking.
## What to do on receipt
1. Read `evt.data.user_id` and `evt.data.id` (the session id). Log the pair with a timestamp: this is your sign-in audit entry.
2. Compare against the user's known devices or IPs if you track them. On an unrecognized device, send the "new sign-in" notice. That notice belongs here, on session creation, not on every request.
3. Trigger first-sign-in onboarding only if this is the user's first session ever. Check your own records; the event itself does not tell you it is the first.
4. Return 200.
## The trap
Treating it as a heartbeat. Token refreshes and active tab use do NOT create sessions, so session.created is sparse. If you need "user is active" data, read session claims server-side per request. If you send a notification per session.created, most users see one per sign-in, which is the correct cadence; per-request would be spam.
## Checklist
- A user with "remember me" signs in rarely and stays signed in for weeks. Your sign-in counts from this event will be much lower than your request counts. That is expected.
- Multi-session users (two browsers, phone plus laptop) generate one event per sign-in per device. Dedupe by session id, not by user id.
- session.created fires after successful authentication, including the second factor when MFA is on. Do not gate on it for step-up auth; the session is fully authenticated at this point.