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.

Call Detail Records (CDRs)​

info

Currently, webhook destination URLs are managed by the didlogic technical team. To set up or modify your endpoints, please contact your account manager or our Support team with the specific URLs you wish to use for each event type.

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.