Commit a stable event before scheduling delivery
Persist the business change and its event intent atomically where your database supports it, using an outbox or equivalent durable mechanism. Keep the Next.js request focused on the application operation rather than waiting for every customer endpoint to respond.
Give the event a unique ID, type, schema version, occurrence time, tenant scope, and an intentionally limited payload. Avoid serializing a raw database row that may expose private fields after a schema change. Document whether recipients receive a snapshot or a reference that requires a subsequent authorized fetch.
Snapshot which subscription receives the event
Represent endpoint subscriptions separately from events and attempts. Store tenant ownership, selected event types, destination version, status, and credential generation. Decide whether subscription changes affect events already queued or only future events.
A delivery should identify its event and intended subscription revision. A customer replacing an endpoint must not accidentally receive an unreviewed backlog at the new address. Provide a clear migration workflow with testing, activation, and a policy for pending attempts.
Treat configurable destinations as an SSRF boundary
An endpoint URL supplied by a customer causes your worker to make a server-side request. Restrict protocols and ports, block internal and special-use destinations, and control redirect behavior. Validate DNS and connection destinations in a way that accounts for rebinding and address changes.
Enforce network-level egress restrictions as well as application validation. Do not let deliveries reach cloud metadata endpoints or internal administrative services. Verification requests and endpoint test buttons need the same protections as production delivery; they are not harmless exceptions.
Sign exact payload bytes with versioned credentials
Define a signature contract covering the intended bytes, timestamp, algorithm, and key identifier. Use a vetted cryptographic library and document receiver verification. A signing secret must remain server-side, excluded from logs, status responses, and support exports.
Distinguish stable event IDs from per-attempt timestamps and signatures. Receivers should deduplicate by event identity and apply a documented freshness window. Support rotation through an intentional overlap or generation policy so queued deliveries do not unpredictably switch verification requirements.
Bound attempts and make duplicate delivery expected
Use a durable delivery record with attempt count, next eligible time, status, and a safe response summary. Apply request timeouts, concurrency limits, backoff with jitter, and an overall retry deadline. Honor receiver rate-limit guidance within your configured delivery policy.
Explain that a timeout may mean the receiver processed the event but the response was lost. Retry with the same event identity and assume recipients must be idempotent. Do not promise global ordering when concurrent workers and retries can reorder arrivals; include a resource revision if consumers need to detect stale updates.
Make replay a privileged, visible operation
After retries are exhausted, retain an actionable failed state rather than an endless queue. Let an authorized tenant operator inspect event type, delivery time, attempt outcomes, and endpoint revision without exposing credentials or unnecessary payload data.
Define replay as a new delivery request for the same event, not a new business event. Record who requested it and which endpoint revision will receive it. Recheck current authorization, retention policy, and subscription state before replay, and prevent accidental replay of another tenant's history.
Operate the sender as a bounded service
Track delivery age, success rate by destination, exhausted retries, concurrency saturation, and disabled subscriptions. One slow customer endpoint must not consume every worker. Isolate scheduling fairly and provide pause controls for failing or abusive destinations.
Test response loss after success, duplicate dispatch, secret rotation, redirect attempts, DNS changes, endpoint deletion, oversized responses, and receiver downtime. Publish a concise customer contract including schemas, retry horizon, signing behavior, and replay semantics before integrations depend on undocumented assumptions.
Check the underlying platform guidance
Use the OWASP SSRF prevention guidance alongside application-specific testing and review.
Build a more dependable Next.js application
Endurance Softwares helps teams design, build, test, and operate production-ready Next.js platforms.