Quick Reference
| Event Type | Trigger | Key Data |
|---|---|---|
esim.created | eSIM purchase complete, data ready | Full eSIM details with QR code |
esim.activated | eSIM activated on device | Status change, activation time |
esim.data_updated | Data usage changes | Usage amounts, remaining data |
esim.usage_updated | Usage requeried | Full usage statistics |
esim.suspended | eSIM suspended | Reason, previous status |
esim.expired | eSIM validity expired | Expiration details |
esim.status_changed | Any other status change | Before/after status |
esim.requeried | Manual data refresh | Updated eSIM data |
Common Payload Structure
All webhooks share this base structure:eSIM Data Object (Common to All Events)
Event Type Details
1. esim.created
When: eSIM purchase completed and resource details retrieved from provider
Timing: 5-30 seconds after purchase
Full Example:
- Update your database with eSIM details
- Send confirmation email with QR code
- Display eSIM in user’s dashboard
- Generate invoice/receipt
2. esim.activated
When: User installs and activates the eSIM profile on their device
Timing: When provider notifies activation (typically within minutes of installation)
Full Example:
activateTime: When activation occurredexpiredTime: Calculated expiration dateeid: Device identifierpreviousStatus: Status before activationnewStatus: “ACTIVATED” or “IN_USE”
- Start usage tracking
- Send activation confirmation
- Update analytics/reports
- Trigger welcome message
3. esim.data_updated
When: Data usage information changes (every few hours or at usage milestones)
Timing: Varies (typically when 25%, 50%, 75%, 90%, 100% thresholds reached)
Full Example:
dataUsage: Current usage in MBdata_usage_remain: Remaining data in MBchanges: Shows what changed from previous state
- Track consumption patterns
- Send low data alerts
- Offer top-up/add-ons
- Update usage charts
4. esim.usage_updated
When: Complete usage information refreshed (data + validity)
Timing: Periodic updates or after manual requery
Full Example:
dataUsage+data_usage_remain: Data usagevalidity_usage_remain: Days remaininglastUsageUpdate: Timestamp of update
- Comprehensive usage sync
- Dashboard updates
- Analytics refresh
- Billing updates
5. esim.suspended
When: eSIM is suspended (manual or automatic)
Timing: Immediately when suspension occurs
Full Example:
REVOKED: Profile revokedCANCEL: Order cancelled
- Notify user of suspension
- Display suspension reason
- Offer reactivation options
- Update access controls
6. esim.expired
When: eSIM reaches end of validity period or data exhausted
Timing: At expiration time or when data runs out
Full Example:
USED_UP: Data fully consumedUSED_EXPIRED: Data used + validity expiredUNUSED_EXPIRED: Expired with unused data
- Archive eSIM data
- Offer renewal/repurchase
- Generate usage report
- Update analytics
7. esim.status_changed
When: Any status change not covered by specific events
Timing: Varies based on status change
Full Example:
- Catch all status changes
- Handle edge cases
- Maintain audit trail
- Debug status transitions
8. esim.requeried
When: eSIM data manually refreshed from provider
Timing: After admin or system requery operation
Full Example:
- Sync latest provider data
- Resolve data discrepancies
- Force update in UI
- Debugging/support
eSIM Status Values
| Status | Description | Triggers Event |
|---|---|---|
PENDING | Order placed, awaiting provider | - |
CREATED | eSIM created, ready for activation | esim.created |
ACTIVATED | Activated on device | esim.activated |
IN_USE | Currently in use (same as ACTIVATED) | esim.activated |
SUSPENDED | Temporarily suspended | esim.suspended |
EXPIRED | Validity expired | esim.expired |
USED_UP | Data fully consumed | esim.expired |
USED_EXPIRED | Data used + validity expired | esim.expired |
UNUSED_EXPIRED | Expired with unused data | esim.expired |
CANCEL | Order cancelled | esim.suspended |
REVOKED | Profile revoked | esim.suspended |
FAILED | Order failed | esim.status_changed |
SMDP Status Values
| Status | Description |
|---|---|
RELEASED | Profile released, ready for download |
DOWNLOADED | Profile downloaded to device |
INSTALLED | Profile installed on device |
ENABLED | Profile enabled for use |
DISABLED | Profile disabled |
DELETED | Profile deleted from device |
Data Units
All data-related fields use megabytes (MB) as the unit:Time/Duration Units
Validity duration typically in days:Timestamp Format
All timestamps are in ISO 8601 format (UTC):Webhook Headers
Every webhook request includes these headers:Signature Verification
Verify webhook signatures to ensure requests are from Vellosim:Handling Webhook Events
Process different event types appropriately:Webhook Response Best Practices
Return 200 Status Code
Return 200 Status Code
Always return a 200 status code to acknowledge receipt. Process the webhook asynchronously if needed.
Respond Within 5 Seconds
Respond Within 5 Seconds
Your endpoint should respond within 5 seconds. For longer processing, queue the webhook for async processing.
Handle Duplicates (Idempotency)
Handle Duplicates (Idempotency)
Webhooks may be sent multiple times. Use the event ID to prevent duplicate processing.
Verify Signatures
Verify Signatures
Always verify webhook signatures to ensure authenticity and prevent spoofing.
Error Handling & Retry Logic
Retry Schedule
Failed webhooks are retried with exponential backoff:- Attempt 1: Immediate
- Attempt 2: 1 minute later
- Attempt 3: 5 minutes later
- Attempt 4: 15 minutes later
- Attempt 5: 1 hour later
- Attempt 6: 2 hours later
HTTP Status Codes
- 2xx: Success, no retry
- 410 Gone: Endpoint invalid, stop retrying
- All others: Retry with backoff
Async Processing Example
Testing Webhooks
Local Testing with ngrok
Expose your local server for webhook testing:Test with webhook.site
Use webhook.site to inspect webhook payloads:- Go to webhook.site
- Copy the unique URL
- Configure it as your webhook endpoint
- Trigger events and inspect payloads in real-time
Integration Checklist
✅ Webhook URL configured in API key settings✅ Signature verification implemented
✅ Idempotency handling (using
event.id)✅ Async processing (return 200 OK immediately)
✅ Error logging and monitoring
✅ Retry handling on your side (optional)
✅ Test with ngrok/webhook.site
✅ Monitor webhook delivery logs
