International Webhooks

Overview

An international webhook is an event-driven callback: connectivity changes are pushed, not polled. It covers event subscription, a real-time callback, a signed payload, and a retry policy. SimtoLink International IoT Cloud Platform (ICMP) delivers those events end to end, across 200+ countries and regions, for 500+ enterprise customers and more than 10 million connected devices.

Subscribe to the events you actually handle

Subscribe by event type: activation, deactivation, a usage alert, a roaming-status change, or a diagnostic event. Point more than one webhook URL at the platform, and let the subscription differ by group or customer.

A signature on the payload

Payloads can be signed with HMAC-SHA256 and checked against a secret, so a forged or altered body is rejected. Delivery uses HTTPS and an idempotency key, so a repeat does not become a second event.

Retry until the delivery log says it landed

A failed delivery can be retried with exponential backoff, up to a maximum you set. The delivery log is there so the attempt can be audited and a lost callback can be found.

What a cross-border event has to satisfy

The push has to be timely across borders, cover more than one event type, follow GDPR and data localization, and be reliable and signed. ICMP provides webhook setup worldwide, event-type management, a delivery log, an API, and monitoring, and the same subscriptions can grow with the business.

How a callback is trusted

Event delivery uses a microservices architecture and an SLA of 99.9%, with technical support 7×24. TLS encrypts the callback, HMAC signs the payload, identity checks sit in front of the configuration, and the audit trail records what was sent.

Events pushed to you, instead of polling several platforms for the same change
A payload signature so a forged or edited event does not enter your system
Retries and a delivery log when a callback fails and someone has to see why
A customer-success manager to register endpoints and stay with the integration

Systems that should hear the event

Status change / lifecycle Activation, deactivation, or usage past a limit is pushed to the business system, so CRM and ticketing can move without a person retyping the change.

Alerts / an operations response A usage alert, a connection fault, or unusual roaming is pushed to operations and the alert platform, so the response can close on the same event.

Data sync / another system Usage and diagnostic events go to BI and billing as they happen, so those systems are not polling and waiting.

From a sandbox callback to production

A workable order is requirements review → solution design → sandbox checks → production cutover → ongoing tuning. SimtoLink configures the webhook, helps choose event types, documents the payload format, and provides a sandbox and integration support. Contact SimtoLink to decide which events your systems should receive first.