How Webhooks Work

When users make updates to a FullStack A/B experiment in PageSense (such as editing variations, changing targeting conditions, or modifying goals), they usually:

  1. Pause the experiment

  2. Apply the required changes

  3. Relaunch the experiment by clicking the Launch button

If a Webhook endpoint has been configured in the Environment Settings, PageSense will automatically trigger a webhook call to that endpoint whenever the experiment is relaunched.

Your system must:

  • Be ready to receive the webhook call.

  • Immediately trigger the getAndUpdateProjectSettings API after receiving the webhook.

  • This ensures that the SDK updates the latest project settings without delay.


Webhook Retry Logic 

If the initial webhook delivery fails (due to network issues or server downtime):

  • PageSense will retry every 30 seconds, for up to 15 minutes.

  • If it still fails after 15 minutes, retries stop.

  • However, if further updates are made and the experiment is relaunched, a new webhook call will be triggered.

Sample Webhook Payload

Copied{
	"projectId": "12345",
	"environment": "production",
	"event": "experiment_relaunched",
	"timestamp": "2025-08-18T10:32:00Z"
}

Differentiating Web-hooks and Polling

Aspect

Polling

Webhooks

Update trigger

Time-based (every X seconds)

Event-based (on relaunch/update)

Freshness

Up to polling delay (e.g., 5–10 min in prod)

Near-instant (seconds)

Reliability

High (simple, resilient to transient issues)

High if endpoint reliable; retries for 15 min

Complexity

Low (one timer + fetch)

Medium (expose endpoint, auth/verify, idempotency)

Failure Behavior

Keeps serving last known settings until next successful poll

Retries (30s for 15 min); requires your endpoint to be up

Best used for

Simplicity, low change frequency

Fast propagation, frequent changes, strict freshness

 

Choose Polling if…

  • You want the simplest setup (no inbound endpoints).

  • Experiments change infrequently or can tolerate a delay.

  • You prefer predictable network usage.

  • You’re in production and OK with, say, a 5–10 minute lag.

 

Choose Webhooks if…

  • You need near-real-time rollout of config changes.

  • You run frequent edits (goals, targeting, traffic splits) during active tests.

  • Staging/QA flows require rapid iteration without waiting for the next poll.

 

Choose Hybrid (recommended) if…

  • You want instant updates via webhooks plus a safety net via polling.

  • You want automatic recovery if a webhook delivery is missed (poll will catch up).

  • Typical setup: Short poll interval in staging (e.g., 10–30s), longer in prod (e.g., 5–10 min), webhook enabled everywhere.