IOSOR Learn

Routing Webhooks Per Sub-Account Without Cross-Tenant Leaks

Master secure webhook isolation for your sub-accounts. Learn to configure tenant-specific endpoints to ensure DLR and status callbacks remain private and metadata-safe.

Routing Webhooks Per Sub-Account Without Cross-Tenant Leaks.

Establishing Tenant-Specific Webhook Architecture

To maintain strict isolation in your white-label CPaaS, you must decouple webhook routing from the primary partner account. When a sub-account triggers an SMS or OTP event, the system generates a unique DLR payload. By assigning a dedicated webhook URL at the sub-account level, you prevent cross-tenant metadata leakage. Navigate to the sub-account settings panel, select the API configuration tab, and define the endpoint for status callbacks. This ensures that every event is routed directly to the client's infrastructure without passing through your global partner listener.

Implementing Secure Payload Authentication

Security is paramount when handling callbacks. Use the HMAC-SHA256 signature verification provided in the header of every webhook request. By generating a unique secret key for each sub-account, you allow your clients to validate that the incoming DLR or Verify OK signal originated from our platform. This prevents unauthorized spoofing and ensures that your clients only process legitimate traffic. Always rotate these keys during the onboarding phase to maintain a proven security posture.

Managing JIT Provisioning and Prepaid Balances

Our platform utilizes JIT provisioning for all numbers, meaning no inventory is held in a static state. When a sub-account requests a number, it is assigned instantly upon payment. Ensure your clients maintain the USD 20 prepaid floor to keep services active. For high-volume partners, we perform a soft review once your monthly spend reaches USD 1,000/month to adjust credit limits and optimize routing paths. This automated approach keeps your operations lean and eliminates the need for manual stock management.

Configuring DLR and STOP Logic

Standardize how your sub-accounts handle incoming signals. Configure the webhook to parse E.164 formatted numbers and map them to the correct internal client ID. When a user replies with STOP, the system must trigger an automated opt-out flag in your database. By centralizing this logic within the sub-account webhook handler, you maintain compliance with global messaging regulations while keeping the partner-level logs clean and audit-ready.

Integrating Essential Partner Resources

To streamline your setup, refer to these documentation paths for deeper technical integration. These guides cover the foundational steps for brand-safe operations and API connectivity:

Start with IOSOR

Open the IOSOR console and navigate to the Partner Settings tab to define your tenant routing rules. Assign explicit, secret-signed webhook URLs for each sub-account to handle DLRs and incoming callbacks independently. Test the routing isolation by triggering a sandbox SMS dispatch per client account and confirming that callbacks fire exclusively to the respective tenant endpoints without leaks.

IOSOR takeaway

This guide established how to isolate sub-account callbacks by binding distinct webhook endpoints and HMAC-SHA256 signing keys to individual client profiles. Decoupling partner-level metadata from end-tenant status callbacks ensures high reliability and complete operational separation across white-label environments.

Do set up unique secret keys and tenant-specific callback URIs during sub-account initialization in your dashboard. Don't route all DLR and Verify payloads through a single monolithic partner endpoint or omit signature verification on incoming traffic.

Was this guide helpful?

Related guides