Let support send one-off Loops emails without an engineer

Build me an internal app my support and ops team opens whenever they need to send a one-off Loops transactional email, so nobody has to ask an engineer to fire an API call. Sending in Loops requires a template ID that references a template published in the Loops UI plus data variables injected at send time, which means a non-engineer literally cannot do it today. This app is the missing screen.

Main screen, the Send tab. Load our published templates with the Loops List Transactional Emails operation (cursor paginated, perPage between 10 and 50, follow nextCursor until it is null) and show them as a picker with the template name and the data variables that template declares. Choosing a template renders a form with one input per data variable for that specific template. Nothing about the form should be hardcoded to a single template.

Recipient discovery works two ways, side by side. Either search our Stripe customers with Search Customers using Stripe's search query syntax on email, name, or metadata, and pick a result to fill in the address; or type or paste an email and look the person up directly in Loops with Find Contact. Either way, show the resolved Loops contact record alongside the form: first name, last name, userId, subscription status, and any custom properties, so the sender can sanity check they have the right person. Important: Loops has no bulk list contacts operation, only lookup by email or userId, so do not design a browse all contacts directory. Discovery is Stripe search or a typed email, full stop. Email values in Loops query params must be URI encoded.

Before the send button enables, gate on suppression. Call Get Contact Suppression Status for the resolved recipient. If they are suppressed, block the send outright and explain why in plain language. Offer a Remove Contact From Suppression List button, and display the remaining monthly removal quota returned by the status check right next to it so the team can see what a reinstatement costs before spending one. After a removal, re-check the status and only then unlock the send.

The send itself goes through Send Transactional Email with the chosen transactionalId, the recipient email, and the data variables. Put a confirmation step in front of it that shows the template name, the resolved recipient, and every variable with its final resolved value, so the sender reads exactly what is about to go out. Generate a UUID idempotency key when the send is confirmed and reuse that same key on any retry, so a double click cannot double send. Reusing a key within 24 hours returns a 409, which should be treated as already sent rather than surfaced as an error. Keep request volume under the baseline of 10 requests per second per team.

Every successful send is appended to a Google Sheet as an audit trail using Append Values: timestamp, which app user sent it, the template name and ID, the recipient email, the Stripe customer ID if that is how they were found, and the data variables as JSON. A second Sent history tab reads that same sheet back with Get Values, newest first, filterable by recipient and by template, so the team can see what has already gone out. When the currently selected recipient and template combination already appears in recent history, warn about it on the send form before they confirm, so nobody sends the same email twice.

Add a "Draft the variables for me" button on the send form that kicks off a background agent. The agent pulls the customer's recent billing activity from Stripe with List Charges and List Invoices filtered to that customer, plus their Loops contact record with Find Contact, then fills in the template's data variables with the correct amounts, dates, and plan names and writes its suggested values back into the form fields. Mark the filled fields visibly as agent suggestions, show the run status while it works, and never send automatically: a human reviews, edits, and approves before anything goes out. If the agent cannot confidently determine a variable, it leaves that field blank with a short note explaining why rather than guessing at a number that will end up in a customer's inbox.

The audit spreadsheet ID and tab name should be configurable in app settings rather than hardcoded, and the sender recorded in the log should be the signed in app viewer, not a shared service account.