docs.wundaflow.com
  • Overview
  • Roadmap
  • Typical use-cases
  • Glossary
  • Core concepts
    • Workflows
    • Tasks
    • Workers
    • Triggers
    • Signals
    • Webhooks
    • Retry policies
    • Wallets
    • KV Store
  • API
    • API Methods
      • Execute a workflow
      • Pause a workflow
      • Resume a workflow
      • Cancel a workflow
      • Check workflow status
      • Poll for notifications
      • Generate a wallet address
      • Read from KV Store
      • Write to KV Store
    • Authentication
    • Connectors
    • Secrets
    • Errors
  • Token
    • Tokenomics
    • Reward pools
  • Wundaverse
    • Intro
    • Randomness
      • Verifiable Delay Function (VDF)
    • Blobbs NFT
    • WundaGames
      • Wundaflip
  • DISCLAIMER
Powered by GitBook
On this page
  • Webhooks
  • Tasks
  1. Core concepts

Retry policies

Webhooks

Webhooks expect an HTTP 2xx response to be considered delivered. By default, we will attempt delivery 5 times before marking a webhook as failed using an exponential back-off algorithm.

Failed webhooks can still be collected from the /webhook/poll endpoint.

Webhooks adhere to an at-least-once delivery policy. This means that we will potentially retry even if your app acknowledges receipt (e.g, if network conditions prevent the request completing, for example).

Tasks

Workflow Task Runs will be retried if they do not return a valid success or error response. While this is handled for you with native tasks, if deploying serverless functions within your own account or using embedded JS tasks, you must always return appropriately to avoid retries.

Should we see a retry level >30%, we will disable your Task Runs and this will render all related Workflow Runs inoperable also.

PreviousWebhooksNextWallets

Last updated 1 year ago