Delivery model
Rangler sends HTTPSPOST requests to every active webhook endpoint in your organization that matches at least one active event subscription rule.
The portal supports multiple active endpoints per organization. Rangler evaluates subscriptions at the organization level, then fans matching events out to each active endpoint for that organization.
The portal lists all supported market-event types, including filings, financial results, corporate actions, board changes, company meetings and streams, and fund updates. Connect has a separate set of event types for connection and synchronization updates.
The payload follows the webhook event format documented in Events.
Send a managed test event
Create an endpoint in the portal, then send a test event from its endpoint actions. You can make the same request through the portal API:202 Accepted after Rangler queues the event with the managed delivery service. Test events appear in endpoint delivery history, so you can inspect status, response code, latency, and failure classification.
Supported managed test types are currently filing.new and fund.disclosure.updated. They validate transport and signing; they are not inserted into the public /v1/events feed.
Example test payload:
Headers
Every webhook delivery includesWebhook-Id, Webhook-Timestamp, and Webhook-Signature.
Webhook-Id participates in signature verification and identifies the managed transport event. The payload’s top-level id identifies the logical Rangler event and is the public key for duplicate-processing protection. Do not assume the two values are interchangeable.
Rangler signs the raw request body using:
Signature verification examples
Use the raw request body exactly as received.- Node.js
- Python
Receiver requirements
Your receiver should accept JSON payloads over HTTPS and use this order of operations:- Read and preserve the raw request body.
- Verify
Webhook-Signature, including the signedWebhook-IdandWebhook-Timestamp. - Parse the payload and atomically insert its top-level event
idinto a durable inbox with a uniqueness constraint. - Return
2xxafter the inbox record is committed. - Process pending inbox records asynchronously and record their processing state.
id already exists, return 2xx without applying its business effects again. Use a database-backed inbox or another shared durable store in production; an in-memory set cannot coordinate replicas and is erased by restarts.
Retries
Rangler treats any non-2xx response, timeout, or connection failure as a failed attempt.
Webhook delivery is at least once. Managed delivery retries use backoff and do not guarantee ordering. Check the portal’s delivery status and next_attempt_at value instead of hard-coding a retry timetable in your integration.
Duplicate delivery is expected behavior, not evidence that Rangler created the underlying event twice. Deduplicate by the payload event id and design business processing so a worker retry cannot repeat an irreversible side effect.
Treat the webhook request as a notification, not as proof that work has completed in your system.
Recent delivery attempts are visible for each endpoint in the Rangler Portal. You can redeliver failed attempts from the portal or through the portal API.
Sandbox testing
Rangler supports managed test events and delivery-attempt inspection from the portal. See Sandbox Testing for the recommended flow.Recommended architecture
1
Rangler sends a webhook event
The delivery arrives as a signed HTTPSPOST request in the documented webhook format.2
Your edge receiver verifies the signature
Validate the signature against the raw request body before doing any downstream work.3
Commit the event to a durable inbox
Uniquely insert the payload eventid and payload. Acknowledge only after that durable write commits; workers can then process the inbox asynchronously.4
Fetch any supporting API data
Pull filing, fund, or entity detail if your workflow needs richer context than the webhook payload carries.5