When Sentinel evolved from a free error log viewer into a premium feature with external notifications, two things became necessary: a way to validate who had paid for that feature, and a server to receive events and dispatch alerts. Neither existed. Both had to be built.
This is the system that took significantly longer to build than DevStudio itself.
A premium feature requires a licensing model. A licensing model requires a server to validate licenses against. A server that receives events from multiple client installations needs to handle deduplication, notification preferences per client, and delivery via multiple channels. And the whole thing needs to be resilient — a client store should not break if the HUB server is temporarily unreachable.
On the payment side, license generation needed to be automatic: when a payment is confirmed via PayPal webhook, a new license is created and assigned.
The system is split into two parts: RT HUB Client, the OpenCart extension installed on the client's store, and RT HUB Server, a separate application hosted on the RandomT server. They communicate via a REST API. The client validates its license against the server on a schedule. The server receives events, deduplicates them, and dispatches notifications.
The architecture deliberately keeps the client store operational even if the server is unreachable — a 7-day grace period allows continued operation before the module is disabled.
License model
Licenses follow the format RTXXX-XXXX-XXXX-XXXX-XXXX. Each license has a plan type (monthly or annual), a domain limit, and a status: ACTIVE, GRACE_PERIOD, EXPIRED or SUSPENDED. The grace period is 7 days — after expiry, the license remains functional for 7 days before being blocked. This prevents a store from breaking due to a missed renewal.
Client-side validation
The RT HUB Client validates its license against the server every hour via a POST call, sending the license key and domain. If the server confirms access_granted: true, the module continues operating normally. Events from Sentinel are queued locally in oc_rt_hub_client_events_queue and sent to the HUB Server every 5 minutes, with retry up to 3 times with exponential backoff.
Server-side event processing
When the server receives an event — either a Sentinel error or a file change — it checks for duplicates within a 5-minute window before storing it. If the same message, file and line appear within that window, it is discarded. Events that pass deduplication are stored and notification records are created with status pending.
A cron job runs every minute, picks up pending notifications, and dispatches them. Email alerts use an HTML template sent via a dedicated SMTP account. Telegram notifications use the Telegram Bot API — the store owner configures a bot token and chat ID. Retry logic handles failed deliveries up to 3 times with exponential backoff.
Notification preferences
Each client has a profile defining alert level threshold (CRITICAL, ERROR, WARNING), which channels are active (email, Telegram), and whether file monitoring is enabled. An event is only dispatched if its severity meets or exceeds the configured threshold.
PayPal webhooks
When a payment is confirmed, a PayPal webhook hits the server, a new license is generated with the appropriate plan type and expiry date, and it is assigned to that payment. No manual intervention required.
API logging
Every API call is logged — endpoint, domain, IP address, response code, timestamp. The dashboard surfaces the last 15 calls. This is useful both for debugging and for monitoring unexpected activity.
A licensing system that validates per domain, handles grace periods, generates licenses automatically on payment, and dispatches multi-channel notifications with per-client configuration. The server dashboard gives a live view of all active licenses, client health, recent events and API activity.
The system is cron-dependent — notification delivery has a maximum delay equal to the cron interval (1 minute). Real-time delivery is not possible in this architecture. PayPal is the only payment provider currently supported.
The licensing infrastructure is in place and running. Future work includes automatic renewal via webhook, Stripe as a second payment provider, and a cleanup cron for events older than 90 days.