Skip to main content

Webhooks

Webhooks allow your application to receive real-time notifications about events occurring within the didlogic platform. Instead of continuously polling our API, didlogic will push data to your server via an HTTP request as soon as a specific event is triggered.

Configure webhook URLs in the API & Webhooks section.

Call Detail Records (CDRs)​

The system sends a JSON payload immediately after a call is terminated. This is essential for real-time billing, CRM logging, or analytics.

Payload Example:

{
  "billsec": 5, // Duration the customer pays for (after the call is picked up)
  "calldate": "2026-05-12T05:17:58Z",
  "callid": "82xg86dv6jhl0p8xu0l3",
  "direction": "outbound",
  "disposition": "ANSWERED",
  "dst": "448081697031",
  "duration": 9, // Total duration of the call, including ringing
  "event": "cdr",
  "src": "441273004315",
  "user_id": 76141
}

Retry Policy​

To ensure data integrity, didlogic implements an automatic retry mechanism if your webhook endpoint is unavailable or fails to acknowledge a request. These events use an Exponential Backoff strategy to provide your server time to recover from temporary outages.

The platform will attempt to send an event 5 times with intervals of ~30s, 1m, 2m, 4m, and 8m (capped at 1 hour).

We allow 5 seconds to establish a connection and up to 15 seconds for the total response.

When we retry:

  • No response/Timeout.
  • Network-level connection errors.
  • Server errors (e.g., HTTP 5xx).
  • Your server explicitly requests a retry (e.g., via a "Retry-After" header).

When we stop immediately:

  • Success: HTTP 200 OK or 3xx Redirect.
  • Final Errors: If your server returns an HTTP 4xx (Client Error), we assume the request is malformed or unauthorized and will not attempt the remaining retries.

After 5 failed attempts, the event is moved to internal "Dead Letter" storage. Our engineering team is alerted to recurring failures at a specific endpoint.

Call Recordings​

Once a call recording is transcoded and successfully stored in our S3 bucket (typically within 3 minutes post-call), a JSON notification is sent containing a pre-signed URL to the .mp3 file.

Payload Example:

{
  "calldate": "2026-05-12T05:17:58Z",
  "callid": "82xg86dv6jhl0p8xu0l3",
  "event": "recording",
  "recording_url": "https://ddl-aws-bucket.com/...",
  "user_id": 76141
}

Retry policy is the same as for the CDR webhook.

Inbound SMS​

When an SMS is received on one of your DID numbers, didlogic relays the message data to your endpoint. Unlike CDRs and Recordings, Inbound SMS notifications are sent as a standard set of parameters (Form-encoded) rather than a JSON object. We automatically handle encoding to ensure the message text is delivered in a human-readable format.

Example Scenario: If your number +448001234567 receives a message "Hello world" from +15551234567 at 12:45 UTC on May 13, 2026, your server will receive:

"src=15551234567&dst=448001234567&message=Hello+world+&received_at=2026-05-13+12%3A45%3A40+UTC"

Retry Policy​

The SMS relay uses a simplified, high-velocity retry logic. The platform will attempt to send an event 5 times. Successive attempts are made almost immediately with minimal delay.

There's a strict 5-second window for connection and response.

When we retry: Any response other than an explicit success/acknowledgement, or if the connection fails.

After 5 failed attempts, the system ceases delivery. Inbound SMS events are not stored in a "Dead Letter" queue and cannot be manually re-sent once the retry limit is exhausted.

Security & Implementation Notes​

  • Endpoint Validation: Currently, didlogic does not provide custom headers or secret keys for request signing. We recommend using a unique, obfuscated URL (e.g., yourdomain.com/webhooks/dlogic_7a8b9c) as a basic security measure.
  • IP Whitelisting: We do not publish a static list of source IP addresses for webhooks as our infrastructure scales dynamically. If your firewall configuration strictly requires an allow-list, please get in touch with support for our current ranges.
    Note: We recommend designing your endpoint to be IP-agnostic where possible, relying instead on URL tokens or application-level validation.
  • Response Requirements: Your server must return an HTTP 200 OK status to acknowledge receipt. Any other status (or a response taking longer than 15 seconds) may trigger the Retry Policy.
  • Asynchronous Processing: To prevent duplicate deliveries (especially for high-velocity Inbound SMS), your endpoint should acknowledge receipt (200 OK) immediately and move the payload to a processing queue.
  • Idempotency: Implement idempotency logic to handle rare duplicate webhooks. Use the callid (for CDRs/Recordings) or a combination of src, dst, and received_at (for SMS) as unique keys in your database.
  • Manual Recovery: While CDRs and Recordings are stored internally upon failure, there is currently no self-service "Re-sync" button. If you experience a major outage, contact support to discuss manual log recovery.