What should you test before approving a HubSpot webhook integration?
The short answer
Require a demonstration of repeated events, delayed events and recovery after an outage, not just a successful first delivery. The integration should reach the correct business state without creating a second deal, sending the same message twice or replacing newer data with an older update.
Key points
- A delivered notification does not prove the business action completed.
- Repeated delivery must not repeat the customer action.
- Delayed events must not overwrite a newer approved state.
- Ask who owns alerts, replay approval and reconciliation after launch.
Official references
Start with the app type and its documented behavior
HubSpot's legacy public app webhook guide explicitly says notifications can arrive more than once and out of order. It also says eventId is not guaranteed to be unique. Those facts make a single successful demonstration insufficient. The guide points project based apps to separate configuration documentation. Have the supplier identify the actual app type and delivery contract rather than assuming the same retry policy applies to every workflow or connector.
A practical acceptance demonstration
- 01Deliver the same sample change twice. Confirm one intended action and an audit record of the repeated delivery.
- 02Deliver a newer state before an older state. Confirm the final CRM record reflects the authoritative current state, including legitimate stage reversals.
- 03Simulate a temporary downstream failure after receipt. Confirm the work remains recoverable and does not disappear behind a successful HTTP response.
- 04Restore the downstream system and replay the failed work. Confirm completed actions are not repeated.
- 05Compare source and destination records for the outage period. Confirm missed changes can be found even after automatic retries stop.
Use an industry outcome, not only a technical counter
For a mortgage workflow, test whether replaying a loan milestone sends a borrower message twice. For field service, test whether replaying a booking creates a second deal. These are proposed acceptance scenarios, not claims about results from a client project. Require the provider to explain how it identifies a business action, verifies current source state and separates processing history from customer communication history.
Deciding whether the connector is ready
Approve the integration only when a named owner can find failed work, explain the affected records and recover it with an audit trail. A connector may be suitable without custom development if it exposes the necessary retry, monitoring and reconciliation controls. If it cannot demonstrate those controls, narrow the automation scope or require additional recovery handling before enabling customer messages.
From our team
How Proven ROI helps
Proven ROI connects CRM and industry systems. The mortgage Encompass and HubSpot case study describes milestone based workflows; it is relevant implementation context, not evidence that a particular webhook delivery guarantee exists.
Talk to a real personCommon follow up questions
- Is an HTTP success response enough to approve the integration?
- No. It confirms receipt at one boundary. Verify the downstream record and any customer action, including what happens if downstream processing fails after receipt.
- Can we use eventId alone to prevent duplicate work?
- Not for the legacy webhook payload described in HubSpot's guide, which says eventId is not guaranteed to be unique. Ask the implementer to document a scoped action identity and prove replay safety.