Notifications Resource
Description
This resource is meant to be used when implementing Verify Push. It lets developers request that Verify Push retry sending a push notification for the same Challenge. Previously, there was a 1:1 mapping between a Challenge and push notification, so developers had to create a new, duplicate Challenge to resend a push notification for the same verification action (e.g. two-factor auth for a user login). They then had to deduplicate the Challenges on the client side. This implementation complexity is removed with this resource.
The Notifications resource is currently in the Pilot maturity stage, please check with Twilio before using it in production.
APNs/FCM behavior: Please be aware that APNs and FCM already have built-in queueing and retry logic for the scenario where the device was offline when the push notification was requested. When the device becomes online again, all non-expired push notifications (based on the push’s time-to-live / ttl) will be sent again. We recommend that developers limit the number of retries a user can request, so that the user doesn’t accidentally “over-request” and end up getting a flood of push notifications. We have also made ttl a configurable resource parameter, so developers can expire past push notifications more quickly if this becomes a problem.
Challenge expiration: Please note that the Challenge itself can still expire. Requesting a retry push notification on an expired Challenge will result in an error response, and developers will need to create a new Challenge. This won’t create a dedup problem for the client-side though, because the client can just request pending, not expired, Challenges.
Notification properties
| Resource Properties in REST API format | |
|---|---|
sid
|
A 34 character string that uniquely identifies this Notification. |
account_sid
|
The unique SID identifier of the Account. |
service_sid
|
The unique SID identifier of the Service. |
entity_sid
|
The unique SID identifier of the Entity. |
identity
|
Customer unique identity for the Entity owner of the Challenge. This identifier should be immutable, not PII, length between 8 and 64 characters, and generated by your external system, such as your user's UUID, GUID, or SID. It can only contain dash (-) separated alphanumeric characters. |
challenge_sid
|
The unique SID identifier of the Challenge. |
priority
|
The priority of the notification. For |
ttl
|
How long, in seconds, the notification is valid. Max: 5 minutes |
date_created
|
The date that this Notification was created, given in ISO 8601 format. |
Resend Push Notification
https://verify.twilio.com/v2/Services/{ServiceSid}/Entities/{Identity}/Challenges/{ChallengeSid}/Notifications
Only 3 Push Notifications can be created per Challenge
Parameters
| Parameters in REST API format | |
|---|---|
service_sid
Path
|
The unique SID identifier of the Service. |
identity
Path
|
Customer unique identity for the Entity owner of the Challenge. This identifier should be immutable, not PII, length between 8 and 64 characters, and generated by your external system, such as your user's UUID, GUID, or SID. It can only contain dash (-) separated alphanumeric characters. |
challenge_sid
Path
|
The unique SID identifier of the Challenge. |
ttl
Optional
|
How long, in seconds, the notification is valid. Can be an integer between 0 and 300. Default is 300. Delivery is attempted until the TTL elapses, even if the device is offline. 0 means that the notification delivery is attempted immediately, only once, and is not stored for future delivery. |
Example 1
Need some help?
We all do sometimes; code is hard. Get help now from our support team, or lean on the wisdom of the crowd by visiting Twilio's Stack Overflow Collective or browsing the Twilio tag on Stack Overflow.
