Best Practices
Implement these best practices when using webhooks.
Security
To improve your security, you may decide to limit the traffic allowed to your servers from our Domains and IP Addresses. Our webhook notifications will always originate from the following IP addresses:
- 84.22.178.192
- 84.22.178.193
- 62.233.96.216
- 62.233.96.217
- 105.29.233.17*
- 105.29.233.2*
SMSPortal's posting engine is highly redundant and load-balanced so please ensure that your endpoint(s) are reachable from all of the above IP addresses.
*Please ensure you whitelist our 2 new IP addresses, as notifications may originate from any of the 6 listed IP addresses.
Response Optimisation
For optimal performance, your web server/application should first receive the data being posted and immediately respond with 200 OK, and then begin to queue the work for asynchronous processing.
This means the data you receive should be stored (cached/queued) and processed separately from the response given. Any complex processing, involving databases or other complex logic, could cause a timeout and you may not receive the posted data again.
Future-proofing
While SMSPortal will never remove or edit existing parameters or error codes to ensure backward compatibility, we may add more at any time. Therefore, in developing and maintaining your code, you should not assume that only the current parameters or error codes exist.
Retry Schedule
SMSPortal waits 10 seconds for a response to all posts. If the endpoint hasn't responded or a temporary error is received, the post is queued for retry up to a maximum of 5 attempts. SMSPortal uses an exponential back-off retry policy for all webhook notifications.
To prevent duplicates, you should store the ID along with your data. Only update your records if the ID is not present in your table - this will enable the handling of multiple submissions of the same event.
Delayed Delivery
As an endpoint experiences delivery failures, SMSPortal will begin to delay the posting and retry of events to that endpoint. For example, if 7 consecutive events posted to an endpoint fail, SMSPortal will assume that the endpoint is experiencing issues and will delay all subsequent retries and new deliveries for some time - in some cases up to several hours.
The functional purpose of delayed delivery is to protect unhealthy endpoints and the SMSPortal system. Without back-off and delay of delivery to unhealthy endpoints, SMSPortal's retry policy and volume capabilities can easily overwhelm a system.
Updated 5 months ago