AtlasWork, planned itself.

The AI-native, all-in-one work platform. Tasks, projects, CRM, contracts, and analytics in one calm workspace.

All systems operational
  • SOC 2 II
  • ISO 27001
  • HIPAA
  • GDPR

Product

  • Overview
  • PDF tools
  • Diagram tools
  • People & HR
  • Integrations
  • Marketplace
  • Pricing

Resources

  • Guides
  • Glossary
  • Compare
  • Docs
  • API reference
  • Support
  • Changelog
  • Status

Company

  • About
  • Careers
  • Press
  • Contact

Legal & trust

  • Trust center
  • Security
  • Privacy
  • Terms
  • DPA
  • GDPR
  • SLA
  • Refunds
  • Google API data
Atlas, a product by wrxstack.com·© 2026 wrxstack·All rights reserved
PrivacyTermsSecurityStatus
Skip to documentation
Docs
Back to Atlas

Start here

  • Overview

Developer

  • REST API guide
  • Authentication
  • API reference
  • MCP (AI agents)
  • SDKs
  • Quick actions

Webhooks

  • Overview
  • Quickstart
  • Events
  • Payloads and headers
  • Security and signing
  • Delivery and retries
  • Managing via API

Connect

  • Connectors
  • Integrations

Product

  • Collaboration and chat

Reference

  • Glossary
  • Keyboard shortcuts
  • Module reference

Webhooks

Delivery and retries

Atlas delivers each event to your endpoint and retries automatically when a delivery fails. This page covers what counts as success, the fixed retry schedule, and how to inspect, replay, and own your webhooks.

Success and failure

A delivery succeeds when your endpoint returns any 2xx status within 10 seconds. Anything else is a failure: a non-2xx status, a timeout (each attempt has its own 10 second timeout), or a network or connection error. Failures are retried on the schedule below.


Retry ladder

On failure Atlas retries automatically on a fixed schedule. There is 1 initial attempt plus 5 retries, for 6 attempts in total. Each delay is measured from the initial attempt time.

AttemptWhen
Initialimmediately
Retry 160 seconds after the initial attempt
Retry 25 minutes later
Retry 330 minutes later
Retry 42 hours later
Retry 512 hours later

After the 6th attempt (Retry 5) fails, the delivery is abandoned and an alert is recorded.

Make your receiver idempotent

Because failed deliveries are retried, your endpoint can receive the same event more than once (at-least-once delivery). De-duplicate using the event id from the body (or the x-atlas-delivery header) so reprocessing the same event is safe.

Delivery history

Every attempt is recorded. You can inspect deliveries for a single webhook or across the whole workspace. Each record shows the attempt number, status code, error kind, and timing.

http
GET /v1/webhooks/{id}/deliveries?limit=50   # history for one webhook
GET /v1/webhook-deliveries?limit=50         # workspace-wide feed across all webhooks

The first endpoint returns the history for one webhook; the second is a workspace-wide feed across all webhooks.


Replay and test

You can re-send past deliveries and send synthetic test events to confirm connectivity.

http
POST /v1/webhooks/{id}/deliveries/{deliveryId}/replay   # re-send a past delivery
POST /v1/webhooks/{id}/test-delivery                     # send a synthetic webhook.test event

Use replay to re-send a past delivery, for example after fixing your receiver. Use test-delivery to send a synthetic webhook.test event and confirm your endpoint is reachable.


Ownership

Webhooks can carry an owner label and an escalation contact so failures reach the right person. When creating or updating a webhook you can set ownerLabel, escalationEmail, and escalationNote. Set these so nobody has to guess who owns a failing endpoint when an alert fires.

On this page

  • Success and failure
  • Retry ladder
  • Delivery history
  • Replay and test
  • Ownership