Webhooks and Events
Webhooks fire HTTP requests when specific things happen in your prototype — a user completes a task, reaches a screen, or triggers a defined event. Event listeners watch for those actions and execute responses. Together, they connect your prototype to external systems like analytics platforms, notification services, and backend APIs.
This turns prototypes from isolated experiences into connected workflow components that integrate with your existing tool stack.
How webhooks and events extend prototype behavior
Without webhooks, prototype test data stays inside PrototypeTool. You review session recordings and manually extract insights. With webhooks, prototype events stream to your analytics platform, Slack channel, or custom dashboard in real time.
This enables scenarios that are impossible with isolated prototypes. A sales demo prototype can create a lead record in your CRM when the prospect reaches the pricing screen. A research prototype can log task completion events to your research repository as participants test in real time.
Webhooks also enable multi-system prototypes. A checkout prototype can send the order payload to a mock fulfillment service and display the response. The prototype behaves like a complete system even though only the frontend exists.
Configuring webhooks and event listeners
- In the project events panel, create a named event for each meaningful action you want to track. Name events descriptively like "checkout-completed" or "feature-tour-skipped" rather than "event-1."
- Attach events to triggers on specific prototype elements. A button tap can fire "add-to-cart," a screen load can fire "pricing-viewed," and a variable change can fire "plan-selected."
- Open the webhooks configuration and create a webhook for each external system you want to notify. Enter the destination URL, select which events should trigger it, and configure the request format.
- Define the webhook payload. Include the event name, timestamp, session ID, and any relevant variable values. Use the payload editor to construct the JSON structure your receiving system expects.
- Set up event listeners for incoming webhooks if your prototype needs to react to external events. For example, an incoming webhook can update a variable value, triggering a prototype state change that simulates a backend response.
- Test webhooks using the event log, which shows every fired event, outgoing webhook request, response status, and payload. Debug delivery failures before deploying the prototype for real testing.
Webhook configuration mistakes
- Sending webhooks to production systems without confirming the receiving endpoint handles test data correctly. A prototype that creates real records in your production CRM causes data contamination.
- Firing events on every user action rather than only on meaningful milestones. Over-instrumentation creates noise in receiving systems and makes it harder to extract useful signals.
- Not including the session ID in webhook payloads. Without session context, receiving systems cannot correlate events from the same test participant.
- Ignoring webhook delivery failures during test sessions. A failed webhook means missing data for that session. Monitor the event log during live testing and have a fallback data collection method.
- Using synchronous webhook responses to gate prototype behavior. If the receiving system is slow, the prototype stalls. Keep webhook calls asynchronous and use optimistic state updates in the prototype.
Monitoring event-driven prototype flows
- Event fire rate: The number of events fired per session. Compare across participants to identify whether some users are not reaching key milestones.
- Webhook delivery success rate: The percentage of webhook requests that receive a successful response. Monitor this during live test sessions to catch integration issues immediately.
- Event-to-action latency: The time between an event firing and the webhook response arriving. High latency indicates integration bottlenecks that may affect the test experience.
- Payload validation rate: The percentage of webhook payloads that pass schema validation on the receiving end. Invalid payloads indicate prototype configuration errors.
When to add webhooks to your prototype
- When you need real-time visibility into test participant behavior in a tool your team already monitors, like Slack, a dashboard, or an analytics platform.
- When testing a multi-system workflow where the prototype needs to communicate with backend services to produce a realistic end-to-end experience.
- When running live demo prototypes where participant interactions should create records in your CRM, support system, or event tracking platform.
- When conducting unmoderated remote tests where you cannot observe participants directly and need automated event data to understand their behavior.
Key concepts
- Webhook: An HTTP callback that fires when a specific event occurs in the prototype, allowing external systems to respond to user actions in real time.
- Event listener: A configuration that watches for specific user actions or system events and triggers a defined response.
- Event payload: The data package sent with a webhook or event, containing details about what happened and the current prototype state.
FAQ
- When should I use webhooks versus in-prototype events? Use webhooks when external systems need to react to prototype events. Use in-prototype events for interactions that stay within the prototype.
- How do I test webhooks during development? Use the event log in the editor to inspect outgoing webhook payloads. Point webhooks at a test endpoint to verify delivery.
- Are webhook deliveries retried on failure? Yes. Failed deliveries are retried up to three times with exponential backoff.
Next steps
Configure one webhook for the event type most relevant to your workflow and verify delivery in your target system. Once the first event flows correctly, expand to additional event types and set up retry monitoring.