Read your webhook delivery log (for non-engineers)

For: An ops lead trying to answer “why didn’t our other system update?” without being an engineer.

You’ll accomplish: finding the delivery log, reading what delivered/failed/dead-letter mean, interpreting the common error codes in plain language, and knowing when to fix it yourself versus forward to an engineer.

A webhook is a message PropSocket sends to one of your other systems the moment something changes — “this lease was updated,” “these residents are new.” Instead of that system asking PropSocket over and over, PropSocket pushes the news to it. The delivery log is the record of every one of those messages: who it went to, when, and whether it arrived.

You don’t need to write code to read the log or take the first troubleshooting steps.

---

1. Find the delivery log

Open Webhooks from the left sidebar — it’s a top-level item, not buried inside an integration. The list shows every webhook you have, one row each, with the destination URL and which integration it belongs to. Click a webhook to open it.

On the webhook’s page, the destination URL is shown at the top, and the delivery history is the Activity Log card lower down. Each row in that log is one delivery attempt.

Each row shows roughly:

• Time — when the attempt was made
• Event — what kind of event it was (a new record, an updated record, a sync finishing)
• Model — the kind of record involved (a lease, a resident), when applicable
• Status — delivered, failed, or dead letter
• Code — a short status number your receiving system replied with
• Latency and Attempt — how long the receiving system took to answer, and which retry attempt this was

The destination URL (the address of the system meant to receive the message) isn’t repeated on every row — it’s shown once at the top of the webhook’s page. Click any row to open the full delivery detail.

2. What the three statuses mean

• Delivered. The message reached your other system and that system accepted it. Nothing to do. If the data still didn’t show up downstream, the problem is inside that other system, not in PropSocket’s delivery.
• Failed. PropSocket tried to send the message and your receiving system didn’t accept it — it was unreachable, rejected the message, or errored. PropSocket automatically retries failed deliveries on a back-off schedule (a few seconds, then minutes, then hours), so a single “failed” often turns into “delivered” on a later attempt without you doing anything.
• Dead letter. PropSocket retried several times over several hours and the message still never got through, so it gave up to avoid retrying forever. This is the status that needs attention — it means your other system genuinely missed that update.

3. Reading the status code in plain language

The status code is what your receiving system told PropSocket. Two families cover almost everything:

• A code in the 2xx range (like 200) means success. Your system said “got it.” These show as delivered.
• A code of 401 or 403 means your receiving system rejected the message as unauthorized. Usually the shared secret or credential your system uses to verify PropSocket’s messages is wrong, missing, or was recently changed. This is a configuration problem on your receiving system — an engineer fixes it there.
• A code in the 5xx range (like 500, 502, 503) means your receiving system had its own error or was down when the message arrived. It’s not rejecting PropSocket; it’s broken or overloaded at that moment. These often clear up on PropSocket’s automatic retry once your system recovers.
• No code at all, or a timeout, means PropSocket couldn’t reach your system’s address — it’s offline, the URL is wrong, or a firewall blocked it.

In short: 401/403 = “your system said no”, 5xx or timeout = “your system was down or unreachable.” Neither means PropSocket lost the data — your records are still safe in PropSocket regardless of webhook delivery.

4. What you can do yourself, and when to forward to an engineer

First, know what PropSocket does automatically: every failed delivery is retried on a back-off schedule (seconds, then minutes, then hours). So if a failure was caused by a brief blip and your receiving system is healthy again, the retry usually turns it into “delivered” on its own — you don’t have to do anything.

Check the endpoint yourself with the Test Webhook button. At the top of the webhook’s page there’s a Test Webhook button. It sends a small test message to the destination URL and records the result in the Activity Log, so you can confirm the receiving system is reachable and accepting messages right now.

Important: Test Webhook sends a fresh test message — it does not re-send the specific update that was missed. There’s no “replay this exact delivery” button today. Use it to check whether the endpoint is healthy, not to recover a missed message. Your records are always safe in PropSocket regardless, and the next change to a record will trigger a new delivery.

So a reasonable self-service flow is: a delivery failed or dead-lettered with a 5xx or timeout → run Test Webhook → if it now shows delivered, the endpoint has recovered and future updates will flow again.

Forward to an engineer when:

• You see 401 or 403 codes — the receiving system is rejecting PropSocket and the fix (the verification secret, the URL, the firewall) lives in their code or config, not in PropSocket.
• Test Webhook still fails, or deliveries keep dead-lettering, which means the underlying problem hasn’t been fixed.
• A genuinely missed update (a dead letter) needs to be recovered. Since there’s no replay button, the engineer who owns the receiving system pulls the current data back from PropSocket’s API. PropSocket has a ready-made, safe-to-re-run recipe for exactly this: Backfill after downtime.
• You don’t know whether the receiving system is healthy. The engineer who built it can tell in seconds.

When you forward to an engineer, point them at the PropSocket webhooks documentation — it covers signature verification and the exact headers, which is usually what a 401/403 comes down to.

5. Share a delivery record with support without leaking secrets

A delivery record can contain real data — resident details, lease terms — and sometimes a signature or secret. When you share one with support or an engineer, share only what identifies the delivery, never the contents:

Safe to share:

• The delivery’s date and time, and its status (failed / dead letter)
• The status code (401, 503, etc.)
• The event type (new record, updated record)
• The integration ID

Do NOT share:

• The full payload (the body of the message) — it may contain resident personal information. Describe it (“a lease update for one of our properties”) rather than pasting it.
• Any signing secret, header value, or token shown on the record.

Support can find the exact delivery from the date, status code, and integration ID alone — no payload needed.

---

If this didn’t work

If deliveries keep dead-lettering after a Test Webhook still fails and an engineer has checked the receiving system, escalate.

Open a support ticket by emailing support@propsocket.io and include:

• Organization slug (the short name in your dashboard URL, e.g. acme-residential)
• Integration ID (the identifier in the integration’s page URL)
• The status code you keep seeing (e.g., “repeated 503s,” “401 on every attempt”)
• The time window the failures fall in
• What you and your engineer have already tried (ran a Test Webhook, checked the receiving system, verified the secret)
• What you expected vs. what you saw

Please do not paste the webhook payload, signing secret, or any header values into the ticket. The integration ID, status code, and time window are all we need.