Webhook Content Delivery Replay Attack Prevention: Use Timestamps, Nonces and Expiring Requests Safely

Webhook content delivery lets one system notify another when an event happens. A payment clears, an order changes, a publishing job completes, or a content asset moves to a new workflow stage. The receiving application then validates the request and acts on it.

That speed is useful, but it also creates a serious security problem. If an attacker captures a valid webhook request, they may be able to send the same request again later. The signature can still be mathematically correct because the request itself has not changed. Your application may then process a duplicate payment instruction, republish an article, trigger a second campaign, or overwrite a newer record with stale data.

This is a replay attack.

A secure webhook delivery model normally combines:

A cryptographic signature, usually HMAC
A request timestamp
A unique nonce or event identifier
A short expiration window
A replay cache or durable idempotency store
Strict request canonicalisation
Operational monitoring and incident controls

The point is not to make requests impossible to resend. Webhook systems need retries because networks fail, servers time out, and queues get delayed. The goal is to make legitimate retries safe while making malicious replays ineffective.

If you publish content through automated workflows, this whole thing matters more than it may first appear. A replayed delivery could create duplicate pages, repeat a product update, launch an unwanted content campaign, or interfere with a content consolidation strategy. Tools such as SEO Letters can help organise publishing workflows, but your webhook endpoint still needs its own verification and governance controls.

What Is a Webhook Replay Attack?

A replay attack happens when someone obtains a valid webhook request and resubmits it to the destination at a later time. The attacker does not necessarily need to understand the full payload. They only need a request that your system will accept.

A simplified request might look like this:

POST /webhooks/content-published HTTP/1.1
Host: example.com
Content-Type: application/json
X-Webhook-Timestamp: 1715000000
X-Webhook-Nonce: 8cc7f1a3-7d64-4f4e-9d71-0d44b8c3ab4e
X-Webhook-Signature: sha256=...

{
  "event": "article.published",
  "article_id": "article_4831",
  "url": "https://example.com/webhooks/seo-guide",
  "status": "published"
}

The receiving server may verify the HMAC signature and conclude that the request came from a trusted sender. That check only proves that the sender knew the shared secret when the signature was created. It does not automatically prove that the request is new.

That distinction is important.

A replay attack in practical terms

Imagine a content platform sends a webhook to your WordPress integration whenever an article is published. The request instructs your system to:

Create a post
Add internal links
Update schema fields
Notify a reporting service
Mark the article as live

An attacker captures the request through a compromised proxy, exposed logs, a vulnerable server, or an incorrectly configured monitoring tool. They then submit it five minutes later, perhaps several hundred times.

Without replay protection, your application could:

Create duplicate posts
Trigger repeated publishing jobs
Send the same notification many times
Consume queue capacity
Distort campaign metrics
Revert a newer state with an older payload
Generate duplicate URLs that increase ranking page competition
Add overlapping pages that contribute to SEO keyword overlap

It can become an operational problem and an SEO problem at the same time.

Why HMAC Signatures Alone Are Not Enough

HMAC is a strong and widely used method for authenticating webhooks. The sender and receiver share a secret key. The sender calculates a digest from the request data, and the receiver calculates it again. If both values match, the payload has not been altered and was probably signed by a party with access to the secret.

A typical construction is:

signed_message = timestamp + "." + nonce + "." + raw_request_body
signature = HMAC-SHA256(secret, signed_message)

The receiver then performs the same calculation.

This protects integrity and authenticity. It does not automatically provide freshness.

If the entire signed message is copied and resent, the HMAC remains valid. The receiver needs additional information that changes over time or can only be accepted once.

Control	What it proves	What it does not prove
HMAC signature	The payload was signed with the shared secret	That the request is new
Timestamp	When the sender claims to have created the request	That the timestamp has not been reused
Nonce	The request has a unique identifier	That the nonce has not already been seen
Expiration window	Older requests should be rejected	That a valid request has not been replayed within the window
Idempotency key	Duplicate processing can be avoided	That the request itself is authentic
TLS	The connection is encrypted in transit	That the sender is authorised at application level

You need these controls to work together. A timestamp without a replay cache leaves a short attack window. A nonce without storage cannot tell whether it was used before. HMAC without either control remains vulnerable to copied requests.

The Core Replay Prevention Model

A dependable webhook verification process should follow a fixed sequence. Keeping the order stable makes the implementation easier to review, test and audit.

Step 1: Read the raw request body

Do not parse and then re-serialise the JSON before validating the signature. Whitespace, property order, escaping and number formatting can change the byte sequence.

Capture the exact body received over the network:

raw_body = request.get_data(cache=True)

The signature should be checked against raw_body, not against a newly generated JSON string.

Step 2: Extract security headers

The receiver should expect a clear set of headers, such as:

X-Webhook-Timestamp
X-Webhook-Nonce
X-Webhook-Signature
X-Webhook-Key-Id

Reject requests when any required value is absent. Do not silently substitute an empty string or a server-generated fallback.

Step 3: Validate the timestamp format

Use a defined format. Unix time in seconds is common because it is simple and language-neutral.

Reject:

Non-numeric values
Values with impossible lengths
Dates outside the allowed period
Timestamps that are too far in the future
Values affected by integer overflow or unsafe conversion

Step 4: Check the age of the request

A basic rule is:

abs(current_time - request_timestamp) <= allowed_window

For many systems, a five-minute window is a reasonable starting point. High-risk actions may need a shorter period, while delayed queue-based systems might require a longer one.

The window should reflect the delivery architecture, not guesswork.

Step 5: Verify the signature with constant-time comparison

Calculate the expected HMAC and compare it using a constant-time function. Regular string comparison may leak timing information in some environments.

hmac.compare_digest(expected_signature, supplied_signature)

The exact implementation depends on your language and framework, but the principle stays the same.

Step 6: Check and reserve the nonce

Look up the nonce in a replay store. If it already exists, reject the request as a duplicate.

If it does not exist, record it before performing the business action. This is where many implementations become unreliable. A simple “check, then insert” sequence can create a race condition when two copies arrive at nearly the same time.

Use an atomic operation:

SET nonce:<value> "received" NX EX 600

In Redis, NX means “only if the key does not already exist”, while EX gives the record a time-to-live. The first request wins. The second is rejected.

Step 7: Apply application-level idempotency

Nonce tracking protects the delivery request. Idempotency protects the business operation.

For example, the same event may legitimately be delivered with a different nonce after a sender retry. If your system only checks nonces, it could process the same content publication twice. Store a durable event ID or idempotency key and make the business operation safe to repeat.

Step 8: Process the event

Only after the request passes authenticity, freshness and uniqueness checks should your application perform the action.

This ordering is worth documenting in your engineering standards because rushed implementations often parse the payload and start work before verification is complete.

Timestamps: How to Use Them Safely

A timestamp limits how long a captured request remains useful. The value is straightforward, but the surrounding details matter.

Use server-side time

The receiver should compare the request timestamp with its own trusted clock. Never ask the client to decide whether the request is current.

Your servers need time synchronisation through a reliable service such as NTP or a managed cloud time source. Clock drift can create false rejections or unexpectedly large replay windows.

Allow controlled clock skew

A timestamp check that allows no tolerance will fail in real environments. Distributed systems do not always agree to the exact second.

A practical configuration might look like this:

Request type	Suggested starting window	Suitable use
High-risk financial action	30 to 90 seconds	Payment or account changes
Standard internal webhook	3 to 5 minutes	Content and workflow events
Delayed queue delivery	10 to 15 minutes	Systems with known queue latency
Long-running offline process	Custom signed expiry	Controlled batch integrations

These are starting points, not universal rules. Measure delivery latency first.

Reject future timestamps

A request from five minutes in the future should not normally be accepted simply because it falls within an absolute difference check. A compromised sender or manipulated clock could create confusing behaviour.

You can use separate limits:

request_timestamp <= current_time + future_skew
request_timestamp >= current_time - maximum_age

For example:

future_skew = 60 seconds
maximum_age = 300 seconds

This allows minor clock differences while stopping clearly invalid future requests.

Sign the timestamp

The timestamp must be part of the signed message. If it is outside the HMAC input, an attacker could change an old timestamp to a recent one.

Correct:

HMAC(secret, timestamp + "." + nonce + "." + raw_body)

Unsafe:

HMAC(secret, raw_body)

with an unsigned timestamp header.

Nonces: Unique Values That Stop Reuse

A nonce is a value intended to be used once. In webhook systems, it generally comes from a cryptographically secure random generator and is included in both the headers and the signed message.

A UUID version 4 can be suitable when generated correctly. A 128-bit random value encoded as hexadecimal or base64 can also work.

A nonce should be:

Generated using a cryptographically secure random source
Unique across the sender’s active delivery period
Included in the signature
Stored by the receiver
Subject to an expiry time at least as long as the timestamp window
Logged carefully without exposing secrets or sensitive payloads

Do not use sequential numbers such as 1001, 1002, 1003. They are predictable and make operational investigation less trustworthy.

Nonce storage needs atomicity

This pattern is vulnerable:

if not cache.exists(nonce):
    cache.set(nonce, "seen")
    process_event()

Two requests can check the cache at the same time. Both see that the nonce is absent. Both then insert it and process the event.

Use an atomic “insert if absent” command or a database constraint. PostgreSQL can enforce uniqueness with a unique index:

CREATE TABLE webhook_replays (
    nonce TEXT PRIMARY KEY,
    received_at TIMESTAMPTZ NOT NULL,
    expires_at TIMESTAMPTZ NOT NULL
);

Then attempt the insert and treat a unique constraint violation as a replay. This is slower than an in-memory cache, but it may be appropriate when the security decision must survive a restart.

Distributed systems require a shared replay store

If your webhook endpoint runs on several containers or servers, a local memory cache is not enough. Request one may reach server A and request two may reach server B.

Use a shared store such as:

Redis with replication and suitable availability controls
A relational database with a unique constraint
A managed key-value store with conditional writes
A gateway-level replay protection service

The right choice depends on your availability requirements and the cost of false acceptance. A content publishing webhook may tolerate a brief outage more easily than a financial transaction endpoint, but duplicate publishing can still damage your data and SEO reporting.

Expiring Requests and the Difference Between Expiry and Idempotency

These ideas are related, but they solve different problems.

Request expiry answers:

Is this delivery still recent enough to accept?

Idempotency answers:

Have I already completed this business operation?

A request can be inside the five-minute timestamp window and still be a duplicate. A retry can arrive outside the timestamp window but carry an event that has not yet been processed.

For reliable delivery, use both controls.

freshness check = timestamp is acceptable
replay check = nonce has not been seen
business check = event ID has not already completed

This three-part model handles a wider range of failures:

A captured request is rejected after expiry
A copied request inside the window is stopped by the nonce
A legitimate retry with a new nonce is stopped by the event ID
A repeated delivery after a timeout can return the previous result safely

Choose an idempotency scope

You need to decide what counts as a duplicate. Options include:

Event ID only
Event ID plus destination
Event ID plus action type
Article ID plus content version
Order ID plus state transition

For a content workflow, article_id alone may be too broad. An article can be updated several times. A better key could be:

article_id + content_version + action

For example:

article_4831:version_7:publish

That lets version 8 publish later without being treated as a duplicate of version 7.

The Signature Input Must Be Precisely Defined

Many webhook failures come from unclear canonicalisation. The sender signs one representation, while the receiver verifies another.

Define the signed string explicitly:

v1.timestamp.nonce.raw_body

Or:

timestamp + "." + nonce + "." + raw_body

Then document:

Header names
Character encoding
Timestamp units
Nonce format
Signature algorithm
Digest encoding
Prefixes such as sha256=
Newline handling
Whether a version field is signed
Key rotation behaviour

A robust signature header might be:

X-Webhook-Signature: v1=sha256=abc123...

Versioning helps you introduce a new algorithm without breaking every existing integration.

Do not sign parsed JSON

These two payloads may represent the same object but produce different signatures:

{"title":"Replay Prevention","status":"published"}

{
  "title": "Replay Prevention",
  "status": "published"
}

Sign the exact bytes. If you need canonical JSON, define a canonical JSON specification and make both sides use it consistently. In practice, signing the raw body is often simpler.

A Practical Verification Example

The following Python example illustrates the flow. It is intentionally simplified and should be adapted to your framework, secret management system and error-handling standards.

import hashlib
import hmac
import time

MAX_AGE_SECONDS = 300
FUTURE_SKEW_SECONDS = 60

def verify_webhook(raw_body, timestamp_header, nonce, supplied_signature, secret, replay_store):
    try:
        timestamp = int(timestamp_header)
    except (TypeError, ValueError):
        return False, "invalid_timestamp"

    now = int(time.time())

    if timestamp > now + FUTURE_SKEW_SECONDS:
        return False, "timestamp_in_future"

    if timestamp < now - MAX_AGE_SECONDS:
        return False, "request_expired"

    signed_message = (
        timestamp_header.encode("utf-8")
        + b"."
        + nonce.encode("utf-8")
        + b"."
        + raw_body
    )

    expected = hmac.new(
        secret.encode("utf-8"),
        signed_message,
        hashlib.sha256
    ).hexdigest()

    if not hmac.compare_digest(expected, supplied_signature):
        return False, "invalid_signature"

    nonce_reserved = replay_store.set_if_absent(
        key=f"webhook_nonce:{nonce}",
        value="seen",
        expires_in=MAX_AGE_SECONDS + FUTURE_SKEW_SECONDS
    )

    if not nonce_reserved:
        return False, "replayed_nonce"

    return True, "verified"

The cache operation must genuinely be atomic. A method named set_if_absent is only useful if the underlying data store guarantees that property.

Also consider what happens after the nonce is reserved but the application crashes before processing the event. That is why a durable event ID and an idempotent business operation are still necessary.

Error Responses and Information Disclosure

Your endpoint should reject invalid requests, but the response should not reveal too much detail to an attacker.

A practical external response might be:

HTTP/1.1 401 Unauthorized
Content-Type: application/json

{
  "error": "webhook_not_accepted"
}

Internally, log a more specific reason such as:

missing_timestamp
invalid_signature
request_expired
nonce_reused
unknown_key_id
malformed_payload

Do not place shared secrets, full authorisation headers or unnecessary personal data in logs. Request bodies can contain customer details, unpublished content or product information, so redact them according to your retention policy.

This matters for governance. A secure endpoint can still become a breach source if observability data stores every secret and payload indefinitely.

Webhook Security for Automated Content Delivery

Content publishing platforms often connect with WordPress, Shopify, webhooks and custom application endpoints. Automated delivery may include article text, metadata, image URLs, schema, internal links and publishing instructions.

A replayed content request can produce more than a duplicate API call. It may change the structure of your organic search programme.

Common content-related replay impacts

Duplicate article creation
Repeated updates to canonical tags
Old content versions replacing current ones
Duplicate product descriptions
Repeated category or tag assignments
Conflicting redirects
Multiple URLs targeting the same keyword
Repeated image uploads
Incorrect publication dates
Reporting inflation

Suppose a workflow publishes three pages targeting variations of “webhook security”. A replay creates two additional versions of one page with slightly different URLs. Search engines may see substantial similarity and unclear page purpose. That can contribute to seo keyword overlap, weak internal linking and diluted relevance.

The security control helps, but content governance has to catch the broader issue.

Connect event identity with content identity

For content systems, create an idempotency key from the content operation:

site_id:content_id:version:operation

Example:

store_92:guide_4831:v4:publish

Store the key with:

First received timestamp
Processing status
Resulting URL
Content hash
Source campaign
Destination
Last update time

This gives your team a useful audit trail when investigating duplicate publication or a suspected replay.

Keyword Cannibalisation and Webhook Governance

Webhook replay attack prevention belongs in the wider security and governance model, especially when automated systems publish at scale.

The connection with keyword cannibalisation is practical. If repeated webhook deliveries create several pages that target the same query, you may see:

Search intent conflict
Ranking page competition
Inconsistent internal links
Multiple pages receiving impressions for one term
Unclear canonical selection
Lower conversion performance
Difficulty deciding which URL should be refreshed

A keyword cannibalization audit can reveal these symptoms, but prevention starts earlier in the publishing workflow.

Add SEO controls to the event payload

A content publication event could include:

{
  "event_id": "evt_99182",
  "content_id": "guide_4831",
  "content_version": 4,
  "primary_keyword": "webhook replay attack prevention",
  "search_intent": "informational",
  "canonical_url": "https://example.com/webhook-replay-prevention",
  "operation": "publish",
  "cluster_id": "webhook-security",
  "published_at": "2025-05-06T10:30:00Z"
}

Your receiver can validate not only the security fields but also whether the requested operation fits your editorial rules.

Reject or quarantine events when:

The content version is older than the live version
The canonical URL already belongs to another article
The keyword is assigned to a conflicting page
The event requests a second page for the same cluster without approval
The destination does not match the authorised site
The source campaign is disabled

This is where an SEO workflow engine can provide meaningful operational value. SEO Letters brings keyword research, topical authority planning, content creation, internal links and publishing workflows into one environment, while your endpoint can enforce the final security and state checks.

A simple content governance matrix

Validation area	Question to ask	Recommended action
Event freshness	Is the request within the permitted time window?	Reject if expired
Event uniqueness	Has this nonce or event ID been processed?	Reject or return stored result
Content version	Is this version newer than the live version?	Quarantine older versions
Search intent	Does the page match the assigned intent?	Send for review if conflicting
Canonical URL	Is the URL unique and authorised?	Reject duplicates
Keyword ownership	Is another page already the primary target?	Run a keyword cannibalization audit
Campaign status	Is the publishing campaign active?	Reject disabled campaigns
Destination	Is the site or store approved?	Reject unknown destinations

Replay Protection in Retry and Queue Systems

Retries are essential. A receiver should not treat every repeated event as hostile.

The sender may retry when:

The receiver returns a 5xx error
The connection drops before the response arrives
A gateway times out
The queue worker restarts
A deployment interrupts processing

The same logical event may arrive with the same nonce or with a new nonce, depending on the sender’s design.

Recommended retry behaviour

For the sender:

Keep the same event ID for every retry
Decide whether the nonce remains the same or changes
Sign every delivery correctly
Use exponential backoff
Stop after a defined retry limit
Send failed events to a dead-letter queue

For the receiver:

Treat the event ID as the business idempotency key
Return the previous successful result for a known completed event
Avoid returning 2xx before durable processing unless the queue design supports it
Record processing state atomically
Distinguish temporary failures from permanent validation failures

A useful state model is:

received -> processing -> completed
                     -> failed_retryable
                     -> failed_permanent

If an event is currently marked processing, a second delivery should not start another job. It can receive a controlled response or wait according to your architecture.

Secret Management and Key Rotation

Replay protection does not compensate for an exposed signing secret. Protect the secret as an application credential.

Use:

A managed secrets vault
Environment-level access controls
Separate secrets for each environment
Different keys for each destination where practical
Restricted staff access
Rotation schedules
Audit logs for secret retrieval

Avoid placing webhook secrets in:

Source code
Public repositories
Client-side JavaScript
Analytics events
Error messages
Long-retention request logs
Shared screenshots

Support overlapping keys during rotation

A safe rotation process usually allows two keys for a limited period:

Generate a new key.
Configure the receiver to accept the old and new key IDs.
Switch the sender to the new key.
Monitor for deliveries signed with the old key.
Remove the old key after the retry window and investigation period.
Confirm that failed requests are not being accepted through a fallback path.

The X-Webhook-Key-Id header helps the receiver select the correct secret. Include the key identifier in the signed context if your protocol requires stronger binding.

Monitoring, Metrics and Alerting

Security controls need evidence. Without metrics, you may not know whether a timestamp window is too narrow, a sender is malfunctioning or an attacker is testing the endpoint.

Track:

Total webhook requests
Accepted requests
Expired requests
Future-dated requests
Invalid signatures
Reused nonces
Duplicate event IDs
Unknown key IDs
Processing latency
Retry counts
Events by source IP or region
Events by campaign and destination
Content versions rejected as stale

Useful ratios include:

replay rejection rate = replayed requests / total requests
signature failure rate = invalid signatures / total requests
processing success rate = completed events / accepted events

A sudden increase in nonce reuse may suggest a sender retry bug, a queue failure or an interception attempt. A rise in valid but duplicate event IDs may indicate that the sender is generating fresh nonces for every retry without preserving business idempotency.

Set alert thresholds based on normal traffic. A small business may investigate any unexpected replay rejection. A large platform may use percentage changes and anomaly detection.

Testing Replay Attack Defences

Do not stop after checking that a valid request works. Test the failure paths directly.

Minimum test cases

Valid request inside the time window
Valid request at the exact expiry boundary
Expired request
Future-dated request
Invalid signature
Altered payload
Altered timestamp
Altered nonce
Reused nonce
Same event with a new nonce
Concurrent duplicate requests
Duplicate event after a worker crash
Unknown key ID
Malformed JSON
Incorrect content type
Oversized payload
Missing required headers
Clock drift between services

Race-condition test

Send the same valid request concurrently from multiple workers. The expected result should be:

One request reserves the nonce and proceeds
The others are rejected as duplicates
One business operation is recorded
No duplicate article, order, notification or campaign is created

This test catches a common flaw that ordinary functional testing misses.

Test content-specific controls too

For publishing systems, verify that:

An old article version cannot overwrite a newer one
A duplicate canonical URL is blocked
A disabled campaign cannot publish
A keyword assigned to one page cannot silently move to another
A failed image upload does not trigger a second full publication
A replayed refresh campaign does not create a new page

This is the point where technical security and editorial governance meet.

A Webhook Replay Prevention Checklist

Use this checklist during implementation or a keyword cannibalization audit of an automated content system.

Authentication and integrity

HTTPS is required for every webhook endpoint
The raw request body is preserved
HMAC-SHA256 or a stronger approved method is used
The timestamp and nonce are included in the signed message
Signatures are compared in constant time
Secrets are stored in a managed vault
Key IDs and rotation procedures are documented

Freshness and uniqueness

The timestamp uses a defined unit and format
Future timestamps are restricted
Expired requests are rejected
Nonces are cryptographically random
Nonces are stored in a shared replay store
Nonce insertion is atomic
Nonce expiry exceeds the accepted request window
Event IDs provide business-level idempotency

Processing and resilience

Duplicate events return a safe, predictable result
Content versions are checked before publication
State transitions are atomic
Queue retries use exponential backoff
Dead-letter handling is available
Worker crashes cannot create duplicate operations
The endpoint limits payload size and request rate

SEO and content governance

Canonical URLs are validated
Content IDs are unique
Primary keywords are mapped to approved pages
Search intent conflict is reviewed
Ranking page competition is monitored
Content consolidation strategy is documented
Duplicate publication events are visible in reporting
Internal links are not repeatedly appended by retries

Common Implementation Mistakes

Mistake 1: Checking the timestamp after processing

The request has already caused harm if verification happens after the publishing job starts. Validate before any business action.

Mistake 2: Storing nonces only in application memory

This fails when the process restarts or traffic reaches another server. Use shared storage.

Mistake 3: Using a long expiry window for convenience

A 24-hour acceptance window gives an attacker plenty of time to reuse a captured request. Measure queue delay and keep the window as short as the system can reliably support.

Mistake 4: Treating a nonce as the only idempotency key

A sender may generate a new nonce during a retry. The event ID or content operation key needs to stop duplicate business processing.

Mistake 5: Parsing JSON before signature validation

This can create signature mismatches and unsafe transformations. Validate the raw bytes first.

Mistake 6: Returning detailed rejection reasons publicly

Specific responses can help attackers refine their attempts. Keep external messages general and internal logs precise.

Mistake 7: Ignoring stale content versions

A valid, fresh request can still carry an older version of an article. Security verification does not prove that the requested state change is logically valid.

Mistake 8: Publishing without search intent controls

Automated systems can create a technically valid but strategically harmful page. This contributes to keyword overlap and makes later consolidation harder.

How SEO Letters Supports a Safer Publishing Workflow

Security controls belong at the endpoint, but a reliable publishing operation also needs planning, content structure and destination governance. SEO Letters is designed for teams that publish for a living, helping move from keyword research to structured articles and scheduled delivery without the copy-paste grind.

Its workflow can support:

Keyword research with difficulty ratings
Topical authority clusters
Competitor site-gap analysis
Search intent mapping
Structured articles with headings and internal links
Schema and image generation
Product-aware affiliate and store content
Publishing to WordPress, Shopify and webhooks
Multi-language generation across 21 languages
Content-refresh campaigns
Performance monitoring after publication

For replay prevention, the important governance principle is simple: every automated content operation should have a clear identity, a current version and an authorised destination.

Your webhook layer verifies that the request is authentic and fresh. Your publishing system verifies that the action makes editorial and SEO sense.

Key Takeaway

A webhook signature confirms that a request was signed by someone who knows the secret. It does not confirm that the request is new.

To prevent replay attacks safely:

Sign the raw body together with a timestamp and nonce.
Reject requests outside a narrow, measured time window.
Store nonces with an atomic insert-if-absent operation.
Use durable event IDs for business-level idempotency.
Account for clock skew, retries and distributed workers.
Validate content versions, destinations and canonical URLs.
Monitor rejection patterns and processing outcomes.
Connect webhook security with editorial governance and SEO controls.

If you’re automating content delivery, do not treat replay protection as a small API detail. It is part of the publishing system’s chain of custody. A stale or duplicated event can create infrastructure noise, inaccurate reporting and genuine search intent conflict across your site.

Build the verification layer carefully, document the rules, and use a controlled workflow such as SEO Letters to plan, produce, refresh and publish content with clearer ownership from keyword to live page. If you need help reviewing the setup, the rightbar is the contact path for discussing your workflow, destination integrations and governance requirements.