Retries & Logs

What happens when your webhook endpoint is slow or down — ConnectSafely's retry policy, timeouts, delivery logs, and how to test your endpoint without waiting for a real LinkedIn event.

What "delivery" actually means

When an event happens, ConnectSafely puts a delivery job on a queue. A worker picks it up and sends the POST to your URL. If your endpoint replies with 2xx, the job is marked done. If not, we retry.

You don't have to set any of this up — it's how ConnectSafely's webhook pipeline works under the hood. This page explains what to expect when things go wrong.

How long do you have to respond?

15 seconds. Your endpoint should return a 2xx response within 15 seconds of receiving the request. If we don't get a response in time, we consider it a timeout and retry.

Tip: don't do slow work inside the webhook handler. Read the body, write it to a queue or table of your own, return 200 immediately, and process it asynchronously. That keeps your endpoint snappy and avoids unnecessary retries.

When do we retry?

We retry on any of these:

Your endpoint replies with a non-2xx status (404, 500, 502, etc.)
The request times out (>15s with no response)
A network error (connection refused, DNS failure, TLS error, etc.)

How many times, and how often?

Attempt	When
1	Immediately when the event happens
2	~10 seconds after attempt 1 fails
3	~20 seconds after attempt 2 fails
(none)	Give up if attempt 3 also fails

Up to 3 attempts total (initial + 2 retries) with exponential backoff starting at 10 seconds. After that we stop. LinkedIn doesn't re-emit the event, so your endpoint should be resilient enough that occasional drops won't break your business logic.

Two important caveats

1. Order isn't guaranteed

If message A fails and has to retry while message B succeeds on the first try, B will arrive at your endpoint before A. Don't assume the order of incoming events matches the order they were sent on LinkedIn.

Use data.timestamp if you need a reliable "when did this actually happen?" value.

2. Duplicates can happen

When we retry, we send the same event again. So if your handler processes the event and then fails to return 2xx (e.g. crash before responding), we'll deliver it a second time and you'll process it twice.

Fix: dedupe on data.message_urn. See the idempotency tip.

Where to look when something goes wrong

Every attempt — successful or not — is recorded in Delivery Logs.

Open the Webhooks dashboard.
Click Logs on the webhook row.

Each row tells you:

Event type and timestamp
HTTP status code your endpoint returned
Round-trip time in milliseconds
First 1,000 chars of the request body and first 500 chars of your response
Attempt number (1, 2, or 3)
The error message if any

Logs are kept for the most recent deliveries. This is the fastest way to debug a webhook that's "not working". 90% of the time the answer is in here — a 401 because your signature check is wrong, a 500 because your handler is throwing, or a timeout because your handler is too slow.

Testing without waiting for a real event

You don't have to send yourself a LinkedIn message to test changes. On any webhook row in the dashboard, click Test. ConnectSafely sends a synthetic message.received payload to your URL with a fake message_urn and account_id, and shows you the response inline.

The test payload uses the same shape as a real payload and includes a valid X-Webhook-Signature — so it doubles as a smoke test for your signature-verification code.

Good habits

Return 200 fast, process slow. Heavy work belongs in your own background queue, not in the webhook handler.
Don't return 200 if you couldn't process the event. Returning 200 while silently dropping the event hides outages from yourself. Prefer 5xx so ConnectSafely retries.
Don't redirect. Webhook deliveries do not follow 3xx redirects. Point the webhook directly at the final URL.
Stick to HTTPS. Plain HTTP works but is discouraged — signatures protect integrity, not confidentiality.

One thing that happens automatically

When you save a new message webhook for a specific LinkedIn account, ConnectSafely opens a real-time stream to LinkedIn for that account so we can actually catch the events. When you delete the webhook (or disable / change its event type so no message webhooks remain on the account), we close the stream. You don't have to manage any of that yourself.