Event forwarding.

apple allows one notification url per app. forwarding removes the choice: RevenueHog relays apple's exact signed payload to your endpoints.

How forwarding works

When Apple posts a Server Notification to RevenueHog, the pipeline verifies the JWS against Apple's root certificates, records the event, acknowledges Apple, and then re-POSTs the verbatim request body to the forwarding URL you configured for that app and environment:

what your endpoint receives

POST https://your-endpoint.example/apple/notifications
Content-Type: application/json

{"signedPayload":"eyJhbGciOiJFUzI1NiIsIng1YyI6WyJNSUlFTUQuLi4"}
   ↑ byte-for-byte the body Apple sent. verify it exactly as if
     Apple had called you directly

Nothing is re-signed, decoded, reformatted or wrapped. The signedPayloadstring your server receives is the one Apple signed, so your existing signature verification (x5c chain to Apple's root, ES256) keeps working unchanged. That's also why no extra HMAC or shared secret is needed: Apple's own signature already authenticates the payload end-to-end, and anyone who can't forge Apple's signature can't forge a forwarded event either.

Endpoints & URL rules

Each app has two optional forwarding URLs, Production and Sandbox, configured on the app's detail page. Production events go only to the production URL, sandbox events only to the sandbox URL; an event whose environment has no URL is recorded in RevenueHog and marked skipped, never mis-routed.

URLs are validated when you save them: they must be HTTPS, must not embed credentials, and must not point at private, loopback or link-local hosts. Standard server-side request forgery protections. If your receiver runs on an internal hostname, put it behind a public HTTPS endpoint first.

Delivery, retries & logging

A delivery succeeds on any 2xx response, with a 15-second timeout per attempt. Failures (non-2xx, timeouts, connection errors) are retried with exponential backoff, three attempts in total; an event that exhausts its retries keeps the failed status and is preserved in a dead-letter set rather than silently dropped.

Every attempt is logged (target URL, attempt number, HTTP status, error) and surfaces on the event's detail view in the live feed and on the webhooks page, so "did my server get it?" has an inspectable answer.

Your downtime never looks like ours to Apple

RevenueHog acknowledges Apple after verifying and recording the event; forwarding happens asynchronously. A slow or down forwarding endpoint therefore can't cause Apple to mark the delivery failed or trigger Apple-side retries.

Downstream verification

Your endpoint should treat forwarded notifications exactly like direct ones: verify the signedPayload's certificate chain and signature, branch on data.environment, and dedupe on notificationUUID(forwarding retries, like Apple's own retries, can deliver duplicates). The Server Notifications V2 guide has working verification code, and the forwarding guide covers building your own relay if you'd rather run one.