Add API-level campaign delivery window pacing#3144
Draft
esokullu wants to merge 2 commits into
Draft
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
This adds campaign-level delivery window pacing so a single campaign can be spread evenly over a configured time window without manually splitting a list into many smaller campaigns.
New API fields:
send_until: absolute timestamp that marks the end of the delivery window.send_window: convenience duration such as24h; it is converted tosend_untilrelative tosend_at, or to the current time whensend_atis empty.Example:
{ "send_at": "2026-07-14T10:00:00Z", "send_window": "24h" }The campaign remains one campaign in the UI/API. It does not create child campaigns or separate drip records.
Why
listmonk already has global throughput and sliding-window rate limits, which are useful for server/provider limits. This patch targets a different use case: per-campaign pacing for sender reputation, warmup, and scheduled newsletter delivery.
Without this, users who want to send one campaign over 12-24 hours have to manually create list segments and schedule many separate campaigns. That fragments analytics and is easy to misconfigure.
Implementation Notes
campaigns.send_untilwith a migration.send_untilon campaign models and API responses.send_windowas an API-only helper field for create/update requests.send_untilmust be aftersend_ator now.last_subscriber_idahead of unsent work and keeps progress on one campaign row.send_until/send_windoware not set.Testing
git diff --checkpasses locally.Follow-up
This is intentionally backend/API-first. If the approach is acceptable, a follow-up can add UI controls such as "Send immediately" vs "Spread over..." to the campaign form.