Delivery & Retries

What counts as delivered

Petify sends each event as an HTTPS POST and waits up to 10 seconds for the answer.

Petify does not follow redirects. A 301 or 302 answer is a failed attempt, so register the final URL.

Do the heavy work after you answer. Verify the signature, store or queue the event, answer 2xx, and process the event in the background.

Retries

After a failed attempt, Petify retries on a fixed schedule. Each delay is counted from the failed attempt and varies by about ±10%.

If attempt 7 fails too, the delivery gets the status Failed and Petify sends nothing more for that event automatically. You can still resend it by hand. If an attempt succeeds, the remaining retries are cancelled.

If you delete the endpoint while a retry is waiting, Petify deletes the delivery and makes no further attempt.

At-least-once delivery and duplicates

Delivery is at least once. Your endpoint can receive the same event more than once, for example when your answer arrives late and Petify retries, or when you resend from the log.

• Deduplicate on webhook-id. It is the same for every attempt, every resend, and every endpoint that receives the event. Store the IDs you have processed, and skip a repeat.
• If you have several endpoints, deduplicate per endpoint.
• Order is not guaranteed. Events can arrive out of order, especially after retries. Do not assume that an event for one job arrives before an event for another job.
• A job can, in a rare re-run, send *.failed and later *.succeeded. The job's poll endpoint stays authoritative: trust its latest answer.

Disabled endpoints and skipped events

You can turn an endpoint off with the Enabled switch, for example during maintenance.

• While the endpoint is disabled, matching events are recorded in the delivery log with the status Skipped. Petify does not send them.
• If you disable an endpoint while a delivery waits for a retry, Petify stops and marks that delivery Skipped.
• Enabling the endpoint again does not send the skipped events. Resend them by hand from the delivery log.
• Send test event still works while the endpoint is disabled.

Resending from the delivery log

Open an endpoint in the Console to see its Delivery log: the events Petify sent to this endpoint, newest first. Filter by status, event type, and date range.

To resend:

• Click Resend on a delivery, or
• Select up to 100 deliveries and click Resend selected.

Rules for a resend:

• You can resend deliveries with the status Delivered, Failed, or Skipped. You cannot resend a Pending delivery.
• The endpoint must be enabled. Enable it first.
• A resend makes one attempt with the original body and the same webhook-id. It does not restart the retry schedule. Treat it as a duplicate and deduplicate as usual.
• After the attempt, the delivery becomes Delivered if your endpoint answered 2xx, and Failed otherwise.
• If one selected delivery cannot be resent, Petify resends none of them and tells you which ones to fix.

Delivery log

The log keeps 30 days of deliveries, then deletes them with their attempts. Deleting an endpoint deletes its log.

Open a delivery to see its event body and every attempt. Each attempt shows the time, status code, error, duration, and the first 1 KB of your response body. When your endpoint rejects an event, the response body often shows why, so return a short error message.

Test events are not recorded in the log.

Recovering missed events

If your endpoint was down for longer than the retry schedule, or a delivery is Failed or Skipped:

• Resend the deliveries from the log while they are within the 30-day retention, or
• Poll the job endpoints for the jobs you are missing. See Registration/Verification/Identification.

Polling by jobId always works, whether or not an event was delivered.