Distillation

Date: Aug 5, 2026

• 🟡 (20:08) User asked whether a Loops workflow could be used instead of the previously suggested approach.
• 🟡 (20:08) Assistant concluded a Loops Workflow is compliant for marketing email but does not provide a broadcast trigger.
• 🟡 (20:08) Assistant stated Loops POST /v1/events/send requires email or userId; each event enters exactly 1 contact into the workflow.
• 🟡 (20:08) Assistant provided example Loops event payload for a single contact: email: "reader@example.com", eventName: "newPost", eventProperties.title: "New post", eventProperties.excerpt: "The first paragraph...", eventProperties.url: "https://example.com/posts/new-post/".
• 🟡 (20:08) Assistant concluded that notifying 1,000 subscribers via Workflow would require sending 1,000 events, one per subscriber.
• 🟡 (20:08) Assistant stated Loops does not expose an API for listing all contacts on a mailing list.
• 🟡 (20:08) Assistant concluded that using Workflow for broadcast would require the repository to maintain its own subscriber database, defeating the simple per-repository action design.
• 🟡 (20:08) Assistant concluded a Workflow triggered by “contact added to list” only works as a welcome sequence and cannot remain waiting to react globally whenever a new post appears.
• 🟡 (20:08) Assistant concluded an “event received” trigger can carry post data, but each event still belongs to only 1 contact.
• 🟡 (20:08) Assistant evaluated a viable Workflow architecture with external subscriber store: 1. signup adds reader to Loops and a private database, 2. GitHub Actions detects a new document, 3. action or backend enumerates confirmed subscribers, 4. sends 1 newPost event per subscriber, 5. active Loops Workflow sends the marketing email using event properties, 6. Loops applies mailing-list, unsubscribe, and double-opt-in rules.
• 🟡 (20:08) Assistant identified added operational concerns for the external-subscriber-store Workflow architecture: service and database overhead, rate limits, partial delivery, retries, and per-recipient idempotency.
• 🟡 (20:08) Assistant restated 2 approaches for new-post emails: (1) pure reusable action with only a Loops API key — new post -> create complete campaign draft -> manual Publish; (2) unattended sending — new post -> external subscriber service -> event per confirmed subscriber -> active Loops workflow.
• 🟡 (20:08) Assistant concluded the Workflow route is sound and compliant, but cannot be implemented with only GitHub Actions and Loops because the action cannot retrieve mailing-list recipients.