Webhook callback disables webhook only after 1 try

JC Uy

We have a webhook created in one of our Smartsheets, and we've been noticing lately that the webhook callbacks immediately disables the webhook after 1 try, causing data discrepancies between the Smartsheet and the system it sends the data to. Here's an excerpt JSON message received from Smartsheet showing the callback only trying once, then disables the webhook immediately:

},
  "stats": {
    "lastCallbackAttempt": "2026-06-17T15:30:06Z",
    "lastCallbackAttemptRetryCount": 1,
    "lastSuccessfulCallback": "2026-06-17T15:29:34Z"
  },
  "disabledDetails": "Maximum callback delivery retries exceeded (1 attempts). Final status: 0, reason: Connection error: timeout",
  "createdAt": "2026-02-09T08:14:45Z",
  "modifiedAt": "2026-06-17T15:30:36Z"

Based on documentation, the Webhook callback attempts 14 times before it disables the webhook. Can someone explain why this disables the webhook only after 1 attempt?

Yulichka

The reason your webhook is being disabled after just a single attempt—despite the documentation stating it should retry 14 times—is almost certainly due to Smartsheet's Ongoing Webhook Verification mechanism rather than a standard event callback failure.

1. Event Callbacks vs. Ongoing Verification

Smartsheet treats standard data events and verification checks differently:

• Standard Event Callbacks (14 Retries): When data changes on your sheet, Smartsheet triggers an event callback. If your server is down or returns a retriable error code, Smartsheet uses an exponential backoff schedule to retry delivery up to 14 times over the span of a couple of days before giving up and disabling the webhook.
• Ongoing Verification Requests (0–1 Retries): To ensure your endpoint is still active and secure, Smartsheet automatically sends a verification "challenge" request to your callbackUrl once every 100 callbacks. If your server fails to respond to this verification challenge successfully (or times out), Smartsheet disables the webhook immediately to protect system resources.

2. Evidence in Your JSON Log

Looking closely at your log timestamps and error details points exactly to a verification timeout:

• The 32-Second Timeout Window: Your lastSuccessfulCallback was at 15:29:34Z, and the failed attempt occurred at 15:30:06Z. This exact 32-second gap perfectly aligns with Smartsheet's standard 30-second network connection timeout threshold plus a brief moment for processing.
• The Error Message: The log states reason: Connection error: timeout. Because your server took longer than 30 seconds to reply, Smartsheet assumed the endpoint was unresponsive or down. Since ongoing verification checks do not get the luxury of the 14-retry cushion, it immediately shut down.

How to Fix and Prevent This

To stop your webhook from unexpectedly disabling, you need to optimize how your endpoint handles incoming traffic from Smartsheet:

• Acknowledge Immediately, Process Later (Asynchronous Architecture): If your receiving application is trying to process the Smartsheet data, update its own database, or run complex code before sending back an HTTP 200 OK response, you will regularly hit that 30-second timeout limit. Your server should immediately return a 200 OK to Smartsheet upon receiving the payload, and then hand off the actual data processing to a background worker or queue.
• Automate Re-enabling: Because transient network blips can happen, a best practice for enterprise integrations is to write a daily script or a failure hook that checks your Smartsheet webhooks via the API (GET /webhooks). If any webhook has its enabled status set to false, the script can programmatically issue a PUT /webhooks/{webhookId} request to flip enabled back to true and re-trigger verification automatically.