API usage
| Check | Why |
|---|---|
| Your API key’s capabilities are scoped to only what it needs | Narrower keys limit the damage if one leaks — see Roles and permissions |
You handle 429 with backoff, not a tight retry loop | See Rate limits |
You retry 5xx responses, but not 4xx | 4xx means fix the request, not retry it — see Errors |
You log request_id from failed responses | It’s what support needs to look up what happened on Get2Dial’s side |
Webhooks
| Check | Why |
|---|---|
| You verify the signature on every delivery | See Verify webhook signatures |
Your endpoint responds 2xx within a few seconds, doing slow work asynchronously | A slow endpoint causes timeouts and unnecessary retries — see Webhook retries and replay |
| Your handler is safe to run twice on the same event | Delivery is at-least-once, not exactly-once |
| You have a plan for checking the delivery log periodically | An endpoint that silently starts failing (a deploy that breaks it, an expired certificate) generates exhausted deliveries nobody notices without checking |
Data handling
| Check | Why |
|---|---|
| You’re not storing more than you need from a webhook payload or API response | Especially recordings and call content — see Security controls |
| You’ve confirmed your use of leads, recordings, or CDRs fits your own retention obligations | Get2Dial’s own retention is platform-managed — see Data retention |