Start by checking the subscription and event conditions:

1.    Notifications Secret:  Confirm there is a value in the Notifications Secret field under Preferences > General > scroll down to Notifications Secret.

If you do not have a value in this field, you’ll need to add one because it’s required to validate your webhooks. A Notifications Secret value is typically a random string, which can include letters, numbers, and a mix of uppercase and lowercase.

Example:  g7Kp2!vR9xL4

2.    Subscription scope: A subscription belongs to a specific customer account. A subscription configured on a different RyderShip customer account will not deliver events for this account.

3.    Event selection: Confirm that the subscription includes the event you expect, such as order.shipped, shipnotice.status_changed, or an inventory event.

4.    Event condition: Confirm that the underlying resource reached the triggering state. For example, an order.shipped notification is associated with the shipped state; an intermediate status may not trigger the event you are expecting.

5.    Endpoint: Confirm the URL is correct, reachable, and configured for the same environment as the subscription.

6.    Current subscription view: RyderShip has had more than one notification path over time. A subscription may appear in the current notification-subscriptions system rather than a legacy notifications screen. Not seeing a legacy record does not, by itself, prove that no subscription exists.

If the subscription is missing or belongs to the wrong account, Support can help correct the configuration and resend eligible notifications where available.

RyderShip records the event being queued for delivery, while the final HTTP request is made by the Notifications service. Check both sides:

*   Check for a value in the Notifications Secret field under Preferences > General > scroll down to Notifications Secret.

If you do not have a value in this field, you’ll need to add one because it’s required to validate your webhooks. A Notifications Secret value is typically a random string, which can include letters, numbers, and a mix of uppercase and lowercase.

Example:  g7Kp2!vR9xL4

*   Search your endpoint, load balancer, API gateway, or firewall logs using the event time and resource ID.

*   Confirm that the endpoint is publicly reachable from the relevant environment.

*   Confirm that your endpoint returns a successful 2xx response after accepting the request.

*   Check for timeouts, connection resets, TLS/certificate errors, redirects, and 4xx or 5xx responses.

*   Check whether a WAF, proxy, or firewall is rejecting the request before it reaches your application.

*   If you need source IP or CIDR allowlisting, contact RyderShip Support for the current environment-specific information. Do not rely on an old allowlist.

If RyderShip can confirm the event was queued but you cannot find a request in your receiver logs, provider the resource ID and timestamp so Support can check the Notifications service delivery path.

RyderShip webhook integrations use HMAC signing. Confirm that: 

*   You have a value in the Notifications Secret field under Preferences > General > scroll down to Notifications Secret.

If you do not have a value in this field, you’ll need to add one because it’s required to validate your webhooks. A Notifications Secret value is typically a random string, which can include letters, numbers, and a mix of uppercase and lowercase.

Example:  g7Kp2!vR9xL4

•    Your application is using the webhook secret for the same environment and customer account as the subscription.

•    The signature is calculated from the exact raw request body, before JSON parsing or reformatting.

•    Your application is reading the expected signature header, such as X-Webhook-Signature, for the integration path being used.

•    The request has not been modified by a proxy, middleware layer, or character-encoding conversion.

•    Sandbox and Production secrets are not being mixed.

If verification suddenly starts returning 401 responses for every Sandbox webhook, it may be a platform configuration issue rather than a problem with your code. Contact Support with the first failure time and a redacted request example; do not send the secret itself.

Sandbox and Production use separate environments, credentials, subscriptions, and IDs. A configuration that works in Production does not automatically apply to Sandbox.

Verify the Sandbox endpoint, OAuth credentials, customer account, subscription, and webhook secret independently. If all Sandbox deliveries fail with 401 responses while Production is unaffected, Support should investigate the platform notification service configuration.

A resend can be a no-op when there is no active webhook subscription matching the customer account and event. This is especially common when:

•    The subscription was created on a similarly named but different customer account.
•    The subscription is inactive, discarded, or configured for a different event.
•    The event was never dispatched because the triggering condition was not met.

First correct or confirm the subscription, then ask Support to resend the specific event or resource where supported

Duplicate deliveries can result from multiple active subscriptions, multiple webhook destinations, receiver retries, or a transient delivery/reprocessing condition. Your receiver should be idempotent:

•    Store a stable event or resource identifier when one is available.
•    Treat a repeated delivery of the same event as safe to ignore after the first successful process.
•    Do not use timestamps alone as a uniqueness key.
•    Review the active subscriptions and destinations before disabling anything.

If two distinct events appear to have identical payloads, send both redacted payloads and their timestamps to Support for investigation.

Webhook delivery is asynchronous. A brief delay can occur while events are queued or while a downstream service is recovering. Broader delays may be associated with:

•    A high-volume burst of updates.
•    Temporary queue or infrastructure pressure.
•    Endpoint timeouts or repeated non-2xx responses.
•    A platform incident affecting RyderShip services.

For a single event, provide the resource ID and event time. For a broad impact, include several examples so Support can distinguish an endpoint-specific issue from a platform-wide issue

Yes. A large burst of events can increase queue and database load, especially when many records are updated at once. Where possible:

•    Avoid unnecessary bulk updates to already fulfilled orders.
•    Use upstream filters to avoid subscribing to changes you do not need.
•    Throttle large backfills or migrations.
•    Process incoming events asynchronously and return a 2xx response promptly.

If a large update is necessary, coordinate with your RyderShip contact before running it.

If an integration reports a payload or request-size error, first capture the event name, resource ID, timestamp, and the exact error response. Do not repeatedly resend a payload that is being rejected for size or validation reasons.

Support may need to review the payload, determine whether it can be safely retried, and advise on a smaller or alternate retrieval pattern. Redact customer data, credentials, tokens, and secrets before sharing examples.

Webhook payloads and API responses are not always identical. Some workflows include details in an event payload that are not returned by a basic polling request. If your integration requires a field that is not present, compare the event payload with the corresponding API resource and contact Support with the event name and missing field.

For example, some shipping workflows rely on the order.shipped event for shipment-specific details. Do not assume that polling the order endpoint alone provides every field delivered by the webhook.

*   Build and validate in Sandbox first.

*   Use Sandbox credentials, IDs, subscriptions, endpoints, and secrets only in Sandbox.

*   Confirm the receiver logs the raw request body, signature result, response code, and correlation information without logging secrets

*   Test one event at a time before running a bulk test.

*   Coordinate test timing with your RyderShip contact when Support or Solutions Architecture assistance is needed.