Definition
Event Subscription allows customers to subscribe to various business events generated by the ICMP platform, such as SIM activation, usage alerts, billing completion, status changes, etc., and push them to the customer system in real time via Webhook. Customers can achieve system linkage, automated operations, and real-time monitoring without polling APIs.
Event Types
Typical subscribable events include: SIM lifecycle—activation success, Suspension, Decommissioning; Usage and billing—traffic over-limit alert, Overage, data plan almost used up, bill generation; Connection status—device online, offline, roaming switch; Abnormal events—abnormal consumption, fraud risk, carrier failure. Customers can select the types of events and filtering conditions (such as specific ICCID, customer, region) according to their needs.
Push mechanism
Event Subscription is usually implemented through Webhook: customers configure the Webhook URL and key on the platform; the platform sends an HTTP POST request to that URL when an event occurs, carrying the event type, timestamp, associated object, and payload data; the customer system receives and processes it (such as updating CRM, triggering alerts, initiating work orders). The platform needs to support retries, signature verification, and failure alerts to ensure reliable event delivery.
Application in ICMP
SimtoLink ICMP supports Event Subscription and Webhook configuration: customers can subscribe to multiple types of events and configure multiple Webhook endpoints; it supports filtering by customer and by project; in cooperation with RESTful API and Audit Trail, it meets integration and audit requirements. Customers can integrate ICMP events with their own operation and maintenance systems, BI platforms, and alert systems to achieve end-to-end automation.
The event types and filter scope a subscription binds
An event subscription is a registration that stays in force: which event types, filtered by what conditions, delivered to which address. The type sets the meaning, for example SIM enabled, usage crossing a threshold, an invoice generated, or a connection lost. The filter scope sets the range, for example only one customer, one batch of SIMs, or one country. A subscription with no filter scope receives every event under the tenant, and both the receiver’s capacity and its permissions are widened.
The subscription itself is not an event. An event is a fact that happens later, with its own identifier, time, and object. One subscription can correspond to many deliveries. What the platform usually promises is at-least-once delivery, not exactly once, and not strict order of occurrence. The receiver has to handle the event identifier. It cannot assume the next push is newer than the previous one. Disabling a subscription stops later pushes. It does not withdraw events already sent.
What a business system needs before it can consume a push
The consumer needs an address the platform can reach, a key for checking the signature, and the ability to return success only after processing has finished. The signature confirms the push came from the platform and the body was not altered. The timestamp rejects a replay that has been held too long. The handling logic must tolerate duplicates: when the same event identifier arrives a second time, return success and do not run the side effect again, for example do not suspend the SIM again or post the charge again. Returning success first, then processing asynchronously in a way that can fail, means the platform will not retry, and the event is lost.
When the address cannot be reached, the platform retries as agreed and finally raises a failure alert. If the receiver returns success while it is overloaded, the platform treats the event as delivered, and the data was never stored. Filter conditions must match permissions. Do not subscribe to another tenant’s SIMs. High-frequency events, such as every attach, are not suited to driving a manual process directly. Aggregate them on the platform first. Together with a webhook, the webhook is only the transport. The subscription decides which events get on it. A consumption result that needs a trace is written to the audit trail. The push log itself does not replace a record of the business action.
Repeated actions when signatures are not checked and duplicates are not removed
Without a signature check, anyone who knows the address can forge an enable or suspend event, and the receiver will change its own system on a false event. Without a time check, an old message that was captured can be submitted again and again. Without deduplication, the platform’s normal retry is treated as a new event. A threshold alert retried three times opens three tickets in the customer system, or posts the same usage three times. Assuming order also fails: a recovery event is processed first, and a fault event that arrives later marks a device that has already recovered as faulty again.
If there is no overlap window while keys are rotated, both old and new signatures fail, and the retry queue fills up. Using the SIM number inside the event as the unique key makes different events for the same SIM overwrite one another. The correct key is the event identifier the platform supplied. A non-success status code should be used only for a temporary failure. A permanent error, such as a wrong filter, should be received again after the subscription is corrected, not left for the platform to retry the same address without limit. At launch, take one real event through a signature failure, a duplicate delivery, and a successful handling, and confirm the side effect happens once. Do not point a production subscription at a test address. A test environment that processes production events will change the state of real SIMs.
A change to the subscription itself should be a traceable action. If a filter change, a signature-key rotation, or disabling an address is not recorded, nobody can later explain why events on a given day suddenly disappeared or were suddenly rejected. Keys should overlap: after the new key starts verifying signatures, the old key is still accepted for a while, so messages already in flight do not all fail. The receiver’s definition of success is that the business store has recorded the event identifier, not that the process received the bytes. Load tests should use a dedicated subscription and a dedicated address. Do not send test events into the production ticketing system. Failures returned by the production address should alert a person, not only increment a counter on the platform.