What is a Delivery Policy?
Your pigeons are the delivery staff. A delivery policy is the reusable set of instructions they follow: timeouts, retries, HTTP preferences, and size limits. Select a policy for each Letter.
Choose how your pigeons deliver
HTTP versions
HTTP/2 is the default. It can negotiate down to HTTP/1.1. HTTP/3 enables QUIC with fallback to older supported versions. The preference does not guarantee the version a server will use.
Two timeouts
Connection timeout limits the wait to reach a server. Response timeout limits the wait for its response. Choose values that suit the endpoint rather than leaving a slow delivery open indefinitely.
Retry policy
Choose up to three additional attempts and which connection errors or HTTP statuses should trigger them. Retries are shared across the entire Letter, including redirects; only a failed hop is retried.
Payload limits
Set request and response header and body limits. A Delivery Policy can use smaller body limits than your plan allows, but cannot raise the plan ceiling.
Create once, reuse thoughtfully
- Create your delivery policy.
Open Delivery Policies on the dashboard and create a policy. Name it for its purpose, such as Staging API, rather than for a single URL.
- Assign it to your Letters.
Select the Delivery Policy in each Letterflow component. A Delivery Policy is region-independent; each Letter chooses where it executes.
- Review shared settings before editing.
Changes apply to future deliveries using this policy. Admitted runs keep their recorded settings. Deleting a policy preserves Letterflow components; select another policy before running their Letterflows again.
The Delivery Policy badge shows your chosen HTTP version. Open a result in the Letterbox to see HTTP Version Used: the version negotiated for the final response.
Retries of state-changing requests can duplicate work. Use an endpoint's idempotency mechanism when available.