New — export finished Stripo emails to Braze as templates, in one batched call
Once an email is built in Stripo, getting it into Braze meant opening each one in the Stripo editor and clicking Export to ESP, one at a time. orbit_export_stripo_email_to_braze does the whole batch in a single call — point it at one Stripo email ID or all forty-two, and each becomes a Braze email template a Canvas can reference. Under the hood it reads each email's rendered production HTML from Stripo and creates the matching Braze template; Liquid like {{custom_attribute.first_name}} carries through untouched, because Braze resolves it at send time, not Stripo. Re-run it and it updates the templates it made the first time instead of piling up duplicates. Stripo has no native export-to-ESP API — the GUI button is the only first-party path — so this reproduces what that button does, programmatically.
What shipped
•New tool — orbit_export_stripo_email_to_braze. Pass a single numeric Stripo email ID or an array (up to 100 per call) and each finished email lands in Braze as an email template, ready for a Canvas to reference. It reads each email's rendered HTML, subject, and preheader from Stripo via GET /emails/<id>, then creates the Braze template via POST /templates/email/create. The job it replaces: opening every email in the Stripo editor and clicking Export to ESP / Braze by hand — fine for one email, a slog for a forty-email program.
•Why a bridge and not a wrapper — Stripo exposes no export-to-ESP endpoint over its REST API. We confirmed it: OPTIONS on the email resource allows only DELETE, GET, HEAD, and OPTIONS, and every plausible export, ESP, and integrations route 404s. The Export to ESP button lives only in Stripo's hosted editor. So the tool does what that button does under the hood — fetch the rendered email from Stripo, create the template in Braze — rather than calling an export API that doesn't exist.
•Liquid survives the round-trip — personalisation tags written into the Stripo email as literal {{...}} stay literal in the exported template, which is exactly right: Braze resolves Liquid at send time, Stripo never should. Each exported email reports a liquid_tag_count so you can confirm the personalisation made it across rather than discovering a flattened tag at send.
•Idempotent re-export — by default every Stripo email becomes a new Braze template. The response hands back a braze_template_map (Stripo email ID to the Braze template ID it created); pass that map on the next run and matched emails update their existing Braze template via /templates/email/update instead of creating a second copy. Re-export as many times as you like without littering the workspace with duplicates.
•Batch hygiene — the tool needs both credential sets, since it reads from Stripo and writes to Braze: an expired token on either side is caught up front. There's a dry_run flag that fetches each email and reports the planned write (name, subject, byte count) without touching Braze, a name_prefix and tags for labelling templates on the way in, and a per-email success/failure breakdown so one bad ID in a batch of forty doesn't sink the rest. It returns IDs, names, template IDs, dashboard URLs, and byte counts only — never the raw HTML, which would blow past the tool-result size limit on a batch of any size.