01
Voice callbacks close call outcomes
Inbound voice, status, and dial-complete events help determine missed, answered, and forwarded outcomes.
Residential HVAC missed-call recovery
Keep working. We’ll handle the callback.
Docs / Webhooks
The webhook surface is provider-facing, auditable, and intentionally not a public event bus
CallSnare currently uses inbound provider callbacks for telephony and billing. These routes ingest provider events, persist evidence, and drive workflow outcomes without turning into a public outbound subscription layer.
The key distinction is simple: provider callbacks feed the product, but the product does not yet expose a public outbound event subscription surface.
Callback model
Voice, SMS, and billing sync feed the same operating system
02
Inbound SMS keeps the conversation current
Customer replies attach to the right lead and stop conditions like STOP or START are handled safely.
03
Billing callbacks keep entitlement in sync
Stripe events reconcile subscriptions, invoices, and billing state into stored org billing records.
Provider callbacks are about ingesting durable facts, not exposing a public customer event API.
Provider callbacks only
These are provider-originated routes, not public customer APIs or broad integration endpoints.
At-least-once reality
Webhook delivery is treated as retryable and idempotency matters for persistence and side effects.
Audit first
Payload evidence is stored so production debugging does not depend on guesswork later.
Current webhook surfaces
The existing callback routes map to telephony and billing facts
Each route exists to ingest a specific provider signal, tie it back to the right organization, and preserve the evidence needed for later debugging or audit.
Twilio inbound voice
Receives the first inbound call webhook, resolves the tracked business number, logs the payload, and returns TwiML quickly.
/api/twilio/voice/inboundProvider callback, not a public customer API.
Supports webhook signature validation when configured.
Designed for at-least-once delivery with auditable persistence.
Twilio voice status
Processes voice call completion state so CallSnare can determine answered, missed, and follow-up outcomes.
/api/twilio/voice/statusProvider callback, not a public customer API.
Supports webhook signature validation when configured.
Writes webhook evidence for debugging and audit.
Twilio dial-complete
Receives dial completion callbacks after forwarding attempts and closes the call outcome cleanly.
/api/twilio/voice/dial-completeProvider callback, not a public customer API.
Works with the voice status path to keep call outcomes reproducible.
Twilio inbound SMS
Receives inbound customer texts, attaches them to the right lead, and handles STOP or START keywords.
/api/twilio/sms/inboundProvider callback, not a public customer API.
Supports webhook signature validation when configured.
Writes webhook evidence for debugging and audit.
Stripe webhook
Synchronizes subscription, checkout, invoice, and customer billing state into OrgBilling and related billing records.
/api/stripe/webhookProvider callback, not a public customer API.
Uses event claiming to stay idempotent under retries.
Supports Stripe signature validation when configured.
Delivery model
The current system ingests provider events. It does not publish a public outbound feed.
If CallSnare later exposes public outbound event delivery, that surface will stay tied to durable business objects such as leads, bookings, and escalation events. That is not public today.
Current routes handle inbound provider callbacks and internal synchronization.
There is no public subscription model for outbound lead or booking events today.
Future event delivery would need the same org-scoped, attributable, durable-object discipline as the protected action surface.
Design principle
Callbacks should persist facts before downstream work gets noisy
01Persist first where practical so retries and duplicates are easier to reason about.
02Return quickly enough for provider expectations instead of blocking on non-critical downstream work.
03Keep webhook logs available so support and engineering can reconstruct the event later.
Continue reading
Webhook behavior usually leads into actions, security, or permissions
Use the next docs to connect the callback model to the protected action surface, credential rules, and broader trust boundaries.
Actions
See which product capabilities are protected, internal, or only planned.
Security
Review validation, rate limiting, attribution, and narrow-default posture.
Permissions
Understand the role and scope model behind protected external access.
Agent access
Check the boundary between public discovery and the protected machine-facing surface.