API and Webhooks
Understand how Prevenue ingests events and sends signed signal payloads.
Prevenue has two API-facing flows:
- Inbound event ingestion sends product or customer events into Prevenue.
- Outbound webhook destinations send signal payloads from Prevenue to your systems.
This article explains how the flows fit together. For full backend ingestion setup, use Direct API Installation.
Inbound ingestion
Inbound ingestion is how Prevenue receives events from your systems. Supported paths include:
| Path | Endpoint type | Best for |
|---|---|---|
| Direct API | /api/events/ingest | Backend source-of-truth product, account, setup, lifecycle, and aggregate usage events. |
| PostHog | /api/events/posthog | Selected PostHog Data Pipelines webhook events. |
| Segment | /api/events/segment | Segment track and group payloads. |
| Web SDK | /api/events/web-sdk | Browser-safe supplemental product events. |
| Stripe | Managed Stripe webhook endpoint | Verified customer billing events through Stripe Connect. |
Workspace identity is resolved server-side from credentials or connections. Do not rely on a workspace ID in the request body as the trust boundary.
Outbound webhooks
Webhook destinations send signed signal payloads to your HTTPS endpoint. Use them when your own system should receive Prevenue signal output.
The webhook destination setup flow lets you:
- Save one or more HTTPS endpoints.
- Store each endpoint URL and signing secret through server-side credential helpers.
- Send a signed test payload to a specific endpoint.
- Rotate a specific endpoint signing secret.
- Disable a specific endpoint.
- Review latest delivery status.
Read Webhook Destination Setup for receiver guidance.
Authentication and secrets
Inbound bearer credentials are generated in Prevenue and shown once. Store them in the sending system and rotate or revoke them from Settings > Integrations.
Outbound signing secrets are used by receivers to verify that a payload came from Prevenue. Rotate them if the receiver may have exposed the secret.
Do not paste raw API keys, bearer tokens, webhook URLs, signing secrets, OAuth tokens, cookies, or auth headers into docs, support messages, logs, screenshots, or Linear comments.
Idempotency and retries
Event and delivery systems should be safe to retry. Use stable event IDs or idempotency keys when sending events. For outbound webhook receivers, store the delivery identifier or idempotency key so repeated deliveries do not create duplicate downstream work.
Webhook replay and retries may evolve by workspace and workflow. Treat each endpoint setup test as the first verification step, then validate the actual Funnel or Signal delivery before relying on it in production.