Proposal Webhooks That Fire the Moment Something Changes
Yes, Smart Pricing Table sends webhooks. Register an HTTPS endpoint, choose which proposal events you care about, and we send a signed JSON payload to your URL the moment each one happens.
Seven events cover the full proposal lifecycle: created, sent, opened, updated by a recipient, pending signature, won, and lost. Stop polling the API on a timer and let your own systems react on the same second your client does.
POST /your-endpoint HTTP/1.1
Content-Type: application/json
Webhook-Id: 8f21c4e0-1d3a-4f9b-a6c7-92be4d1f7a05
Webhook-Timestamp: 1786291200
Webhook-Signature: t=1786291200,v1=k9Xp2R...
{
"id": "evt_7d2c91af",
"type": "proposal.won",
"created_at": "2026-08-10T16:04:11.000Z",
"data": { /* the full proposal */ }
}Every delivery is signed with HMAC-SHA256 so you can verify it came from us.
Seven Events Across the Proposal Lifecycle
Subscribe every endpoint to all seven or just the one you need. A build server that only cares about closed deals can listen for proposal.won and ignore the rest.
proposal.createdproposal.sentproposal.openedproposal.recipient_updatedproposal.pendingproposal.wonproposal.lostThe recipient events are the ones you cannot get anywhere else. Because Smart Pricing Table builds interactive pricing tables where clients pick options and set quantities themselves, a webhook can tell you that someone raised their seat count from 10 to 25 while they were still reading. That is a buying signal on a proposal you have not even followed up on yet.
The Whole Proposal, Plus What Actually Changed
Every event arrives in the same envelope: an event id, the event type, a created_at timestamp, and a data object holding the full proposal in the same shape the REST API returns.
Recipient events add a change object so you do not have to diff anything yourself. It names the action, the item involved, and the old and new values.
Internal notes, CRM connection details, and anything secret-shaped are stripped before the payload leaves us, so a webhook receiver never sees the private side of a proposal.
Headers on every request
Webhook-Signaturet=1786291200,v1=<base64 HMAC>HMAC-SHA256 of the timestamp and body, keyed with your endpoint secret.
Webhook-Timestamp1786291200Unix seconds. Reject anything older than five minutes to stop replays.
Webhook-Id8f21c4e0-1d3a-...Stable per delivery, so you can make your handler idempotent.
{
"id": "evt_7d2c91af",
"type": "proposal.recipient_updated",
"created_at": "2026-08-10T16:04:11.000Z",
"data": {
"id": "prop_4b81e2",
"name": "Website Redesign - Northwind",
"status": "SENT",
"pages": [ /* groups, line items, pricing */ ]
},
"change": {
"action": "quantity_changed",
"line_item_name": "Managed Workstations",
"old_quantity": 10,
"new_quantity": 25
}
}Verifying a delivery
Concatenate the timestamp and the raw request body with a period between them, run HMAC-SHA256 over it using your endpoint secret, base64 the result, and compare it to the v1 value in the signature header. Endpoint secrets start with whsec_ and are shown once when you create or rotate them.
Built to Survive Your Endpoint Being Down
A webhook you cannot trust is worse than no webhook, because you build on it and then quietly miss deals. Deliveries are retried, logged, and replayable.
The retry schedule
Each delivery waits 15 seconds for a response. Anything in the 2xx range counts as delivered. A hard 4xx means your endpoint rejected the payload on purpose, so we stop rather than hammer you.
Eight Attempts, Backing Off
Timeouts, 429s, and 5xx responses get retried on a widening schedule that reaches out to 24 hours. A receiver that is down for a morning still gets the event.
A Delivery Log You Can Read
Expand any endpoint to see recent deliveries with the HTTP status, the response time, the error, and a snippet of what your server actually returned.
Send a Test Event
One click posts a sample payload to your endpoint so you can confirm your receiver works before a real proposal depends on it.
Manual Retry
Fixed the bug after a delivery already failed? Hit Retry on that delivery and it goes back in the queue instead of being lost.
HTTPS Only
Endpoints must be HTTPS, URLs with embedded credentials are rejected, private and internal addresses are blocked, and redirects are not followed.
Pause Without Deleting
Flip an endpoint to paused during a deploy or a migration, then turn it back on. Up to ten endpoints per account, each with its own event list and secret.
The Work That Used to Happen After Someone Noticed
Most of the delay between a signature and the actual start of work is somebody finding out. Webhooks remove that gap.
proposal.wonClose the deal everywhere at once
Move the opportunity to won in your CRM, kick off the onboarding checklist, create the project, and notify the delivery team. One event, no copy and paste.
proposal.wonInvoice without re-entering anything
The payload carries the accepted line items and totals, so your billing system can raise the first invoice from what the client actually selected.
proposal.openedCall while you are still on their mind
Post to a Slack channel the moment a proposal is opened. Reaching out during the read is a very different conversation than following up three days later.
proposal.recipient_updatedCatch upsells as they happen
A recipient raising a quantity or adding an optional item is the clearest buying signal you will get. Route it to the rep who owns the account.
proposal.sentKeep your own reporting honest
Stream every send, open, and outcome into your warehouse or dashboard so proposal metrics live next to the rest of your funnel.
proposal.pendingChase signatures automatically
When a proposal sits in the signature flow, start a reminder sequence and stop it the moment the won event lands.
You do not need a developer for most of this. Any automation platform that accepts an incoming webhook, including Zapier, Make, and n8n, can catch these events and pass them along to the tools you already pay for. If you would rather work in the other direction and have your systems drive the proposal, that is what the REST API and our other integrations are for, and the two work well together.
Live in About Five Minutes
No sales call, no engineering ticket on our side. If you have a URL that can accept a POST, you can be receiving events today.
Open Integrations, then Webhooks
Webhooks live in the Integrations area of your account, next to your API keys and CRM connections.
Add an endpoint
Paste the HTTPS URL that should receive the events. A short description helps when you have several, for example "Slack alerts via Zapier".
Choose your events
All seven are selected by default. Turn off the ones you do not want so your receiver is not handling traffic it will ignore.
Save the signing secret
The secret is shown once, when you create the endpoint. Store it with your other credentials. You can rotate it later if it ever leaks.
Send a test event
Confirm your endpoint returns a 2xx before a real proposal depends on it, then watch the delivery log as live events start arriving.
Webhooks are available on plans that include API access, and an account admin or owner manages the endpoints. See pricing and plans for the details, or read the API documentation if you want to pair events with direct calls.
Want to See It Against Your Own Workflow?
Webhooks FAQ
Common questions about proposal webhooks, payloads, and delivery in Smart Pricing Table.
Does Smart Pricing Table support webhooks?
Yes. You can register HTTPS endpoints that receive a signed JSON POST whenever a proposal event happens. There are seven events covering the proposal lifecycle: created, sent, opened, updated by a recipient, pending signature, won, and lost. Each endpoint subscribes to whichever events you choose, and webhooks are available on plans that include API access.
How do I get notified when a proposal is signed?
Subscribe an endpoint to the proposal.won event, which fires when a proposal is accepted or fully signed. The payload includes the complete proposal, so your CRM, invoicing, or project setup can act on exactly what the client agreed to. If several people need to sign, the proposal.pending event fires when the proposal first enters the signature flow, so you can track deals that are partway through.
What does a Smart Pricing Table webhook payload look like?
Every event uses the same envelope: an event id, the event type such as proposal.won, a created_at timestamp, and a data object containing the full proposal in the same shape the REST API returns. Recipient events add a change object naming the action, the item involved, and the old and new values, so you do not have to compare payloads yourself. Internal notes, CRM connection details, and secret-shaped fields are removed before delivery.
How do I verify that a webhook really came from Smart Pricing Table?
Every request carries a Webhook-Signature header in the form t=timestamp,v1=signature. Join the timestamp and the raw request body with a period, compute an HMAC-SHA256 over that string using your endpoint signing secret, base64 encode it, and compare it to the v1 value. Also reject requests whose Webhook-Timestamp is more than five minutes old to prevent replays. Secrets begin with whsec_ and are displayed once when you create or rotate an endpoint.
What happens if my endpoint is down when an event fires?
The delivery is retried up to eight times on a widening schedule that runs from about 30 seconds out to 24 hours, so a receiver that is offline for a few hours still gets the event. Timeouts, 429 responses, and 5xx responses are retried. A hard 4xx is treated as a deliberate rejection and is not retried. Every attempt is logged with its status and response, and you can manually retry any failed delivery once you have fixed the problem.
Can I use webhooks with Zapier, Make, or n8n?
Yes. Any automation platform that gives you an incoming or catch webhook URL will work, because we simply POST JSON to the HTTPS endpoint you provide. That covers Zapier, Make, n8n, and most similar tools, and it means you can connect proposal events to Slack, spreadsheets, or your project management app without writing code.
How are webhooks different from the API?
The API is for asking and telling: your code calls us to create a proposal or read its current state. Webhooks are the reverse direction, where we push an event to you the moment something changes. Without them you would have to poll the API on a schedule and still find out late. Most teams use both, with the API to build and update proposals and webhooks to react to what recipients do.
Can I see whether a webhook was delivered?
Yes. Expanding an endpoint shows its recent deliveries with the resulting HTTP status, how long the request took, any error message, and a snippet of the response your server returned. You can also send a test event to a new endpoint to confirm it works before a live proposal depends on it, and pause an endpoint during a deploy without deleting it or losing its configuration.