Connections

Wire Wisegrid into your stack, without waiting on us.

Outbound webhooks fire on the row events you choose, signed so the receiver can trust them, and every attempt is logged. You don’t need a native integration to push your data where it needs to go.

connection · outbound webhook
Endpointhttps://hooks.acme.io/wg
Signing secretwhsec_••••••5f2a
Fires on
row.created
row.updated
row.deleted
rows.bulk_updated
HMAC-signedSSRF-guarded

Point a webhook at any URL, pick the events that fire it. Signed and hardened before the first POST goes out.

events

Fire on exactly the changes you care about

Subscribe a webhook to row created, updated, deleted, or a bulk update, or all of them. A bulk operation collapses into one event per sheet, not one POST per row, so a big edit doesn’t flood your endpoint.

Pick the events
Created, updated, deleted, or bulk, per webhook, so each integration hears only what it needs.
Bulk-safe
A bulk change sends one event per sheet instead of one POST per row.
connection · events
row.createdone per new row
row.updatedcell or status change
row.deletedrow removed
rows.bulk_updatedcollapses to one event
subscribe per webhookbulk = one POST, not thousands
signed · guarded

Signed so you can trust it, hardened so it can’t be turned on you

Each payload is HMAC-SHA256 signed with a per-webhook secret in anX-Wisegrid-Signature header, the same pattern Stripe uses. Private, loopback, and link-local addresses are blocked, HTTPS is required, and redirects are off. Checked when you save the URL and again on the resolved IP at send time.

Verify the signature
Per-webhook secret over the body; confirm it on your side and you know it’s really us.
Hardened against SSRF
No private IPs, HTTPS only, no redirects. Re-checked at send so DNS-rebind tricks fail.
POST /hooks/acme · payload
X-Wisegrid-Signature: sha256=9f2c…a17b
{
  "event": "row.updated",
  "sheet_id": "sht_8fa2",
  "row_id": 482,
  "delivered_at": "2026-06-28T09:41:02Z"
}
HMAC-SHA256 per-webhook secret
Private IPs blocked, checked again at send
HTTPS only, redirects disabled
delivery log

See every attempt: status, retries, timing

Open any connection to see its deliveries: the event, an ok/fail pill, the HTTP status, the live attempt count with the next retry time, and the timestamp. The classic “did my webhook actually deliver?” question, answered, with no secrets or URLs exposed in the log.

A log per webhook
Event, status, attempt count, and time for each delivery, with the next retry time while it’s still retrying.
Safe to share
The log shows what happened without leaking the secret or the target URL.
connection · delivery log
Event
Status
Attempt
When
row.updated
200
attempt 1
09:41:02
rows.bulk_updated
200
attempt 1
09:38:11
row.created
200
attempt 1
09:36:44
row.updated
503
attempt 3 · next retry 09:36
09:30:00
one row per delivery, updated in placeno secrets or URLs exposed
self-healing

Retries with backoff, then a graceful give-up

A failed delivery retries on a growing backoff. Consecutive failures are counted, and after a sustained run the webhook auto-disables so a dead receiver stops getting hammered on every row change. Fix it, re-enable it, and the counter resets on the first success.

Backoff retries
Transient failures retry on a growing delay (1m, 5m, 30m, 2h, then 6h) instead of giving up immediately.
Auto-disable & reset
A persistently dead endpoint is paused; re-enabling clears the counter on first success.
connection · recovery
09:30:00Attempt 1 → 503
Endpoint returned an error
09:31:00Retry · backoff 1m
Failed again. Count = 2
09:36:00Retry · backoff 5m
Still failing. Count climbs
-Auto-disabled
Dead endpoint stops getting hammered
on fixRe-enable → first success
Counter resets to zero
quiet · roadmap

Quiet during imports, with connectors on the way

A bulk Smartsheet import doesn’t fan out thousands of POSTs: import-sourced events are skipped, so your integrations see real changes, not migration noise. Native Slack and Teams connectors aren’t built yet; until then, webhooks reach them in a couple lines of glue.

Quiet during imports
Import-sourced events are skipped so a migration doesn’t spam your endpoints.
Connectors on the roadmap
Slack and Teams are planned with a “notify me” toggle. Your interest sets the order.
connection · quiet by default
Importing 12,540 rows…
Webhooks paused for this import: your endpoint sees real changes, not migration noise.
Native connectors
SlackNotify me
Microsoft TeamsNotify me
reach them today via webhookyour vote sets the order
Frequently asked
Does Wisegrid have native integrations like Slack, Teams, or Jira?
Not as built-in connectors yet. Those are on the roadmap (the connector panel has a "request a connector" capture so your interest sets the order). What ships today is outbound webhooks: you point one at any HTTPS endpoint and reach Slack, Teams, Zapier, Make, or your own service in a couple of lines of glue, without waiting on us to build a dedicated connector.
How do I connect Wisegrid to other apps?
Through per-sheet outbound webhooks. On a sheet you can manage (editor or owner), add a webhook with a target URL and the row events it should fire on. From then on, a matching change POSTs a JSON payload to that URL. Anything that can receive an HTTPS POST (Zapier Catch Hook, Make, n8n, a serverless function, your backend) becomes a connection.
Does Wisegrid have webhooks like Smartsheet?
Yes. Wisegrid fires outbound webhooks on row changes. You subscribe each webhook to the events you care about (row created, updated, deleted, or a bulk update), and every matching change sends a signed JSON POST to your endpoint. You can run up to 10 webhooks on a single sheet, each pointed at a different URL with its own event subscription.
Which row events can a Wisegrid webhook fire on?
row.created, row.updated, row.deleted, and rows.bulk_updated. You pick the subset per webhook, so an integration that only cares about new rows never hears about deletes. A bulk paste or bulk edit collapses into one rows.bulk_updated event per sheet, so a large change sends one POST per webhook instead of one POST per row.
How do I verify a webhook actually came from Wisegrid?
Each delivery is signed with HMAC-SHA256 using a per-webhook secret, sent in an X-Wisegrid-Signature: sha256=... header. On your side you recompute the HMAC of the raw request body with the same secret and compare. This is the same pattern Stripe uses for its inbound signatures. The secret is generated when you create the webhook and shown once so you can copy it; the delivery log never echoes it.
Can a webhook point at an internal or localhost URL?
No, and that is deliberate. The target URL is checked against an SSRF guard that blocks private, loopback, and link-local addresses and requires HTTPS. A bad URL is rejected with a clear error before it ever saves. The check runs again at send time against the freshly resolved IP, so a hostname that later re-points at an internal address (a DNS-rebind) is caught and not delivered. Redirects are disabled, since a 302 to an internal host is the classic bypass.
What happens if my webhook endpoint goes down?
A failed delivery retries on a growing backoff: roughly 1 minute, then 5 minutes, 30 minutes, 2 hours, and 6 hours before giving up. The scheduled retries are persisted, so they survive a process restart or a blue/green deploy. After a sustained run of consecutive failures the webhook auto-disables so a dead endpoint stops getting hammered on every row change. Fix it, re-enable it, and the first success resets the failure counter to zero. A 410 Gone disables it immediately, since the receiver is telling you the endpoint is gone for good.
Will a big Smartsheet import flood my webhook with thousands of calls?
No. Import-sourced row events are skipped entirely, so migrating a 10,000-row Smartsheet workspace does not fan out 10,000 POSTs. Your integrations see real, interactive changes (user edits, form submissions, automation writes), not migration noise. The importer is not a webhook trigger.
Can I see whether a webhook actually delivered?
Yes. Each webhook has its own delivery log. For every attempt it records the event, whether it succeeded, the HTTP status code, a short diagnostic on failure, the attempt count, and the next scheduled retry time while it is still retrying. The log is safe to share with teammates: it has no column for the signing secret or the target URL, so it cannot leak either.
What does the webhook payload contain, and does it include personal data?
The JSON body carries the event name, the sheet and row ids, the change source, a delivery timestamp, the row version, and the cell values before and after the change. For the person who made the edit it includes their display name only. It never includes their email address or user id, the same name-only rule the activity log follows.
How is Wisegrid Connections different from Smartsheet integrations?
Smartsheet leads with a catalog of prebuilt connectors. Wisegrid leads with a signed, hardened outbound webhook you control, so you are not blocked waiting for a specific connector to exist. You get HMAC signing, an SSRF guard rechecked at send, automatic retries with backoff, auto-disable on dead endpoints, and a per-webhook delivery log out of the box. Native connectors are being added on top of that foundation, with the order driven by what users request.
Do I need to write code to use connections?
You need an endpoint that can receive an HTTPS POST. If you already use Zapier, Make, or n8n, their generic webhook trigger gives you that with no code, and you build the rest of the flow visually. If you run your own service, you add a small route that verifies the X-Wisegrid-Signature header and reads the JSON body. Either way, setup on the Wisegrid side is just a URL plus the events you want.

Try it on your sheets.

Start your 7-day free trial, no credit card required, or migrate your Smartsheet workspace with one token.