Fixed — deleting or exporting a batch of Stripo emails works in one call again
Hand orbit_delete_stripo_email or orbit_export_stripo_email_to_braze an array of email IDs — say all 36 in a program at once — and the call failed with Email IDs must be numeric Stripo email IDs. Got: "[...]". Single-ID calls were fine, so the only way through was 36 separate one-at-a-time calls. The cause was a stringified array: both tools accept a single ID or an array, and because the input is allowed to be a plain string, the desktop client is free to send your array as JSON text — [101, 102, 103] arrives as the literal string "[101, 102, 103]". The tool read that string as one ID, found it wasn't a number, and rejected the whole batch. Both tools now detect a JSON-encoded array or object and unwrap it back into a real list before validating, so the batch path works whether the client sends a real array or a stringified one.
What shipped
•Bug fix — orbit_delete_stripo_email and orbit_export_stripo_email_to_braze now unwrap a JSON-stringified array of IDs before validating it. Both tools advertise that their ID input can be a single value or an array; because a plain string is also valid, the client can serialise an array argument to text, and your [101, 102, 103] lands as "[101, 102, 103]". The validator read that one string as a single ID, saw it wasn't numeric, and failed the batch. They now parse the string back into a list first, so a batch of 36 IDs goes through in one call instead of degrading to 36 separate fallbacks.
•Same fix on the export tool's braze_template_map — the parameter that maps each Stripo email to the Braze template it should overwrite had the identical stringified-input problem, so a map passed as JSON text was unwrapped the same way. orbit_compose_stripo_email was audited for the same pattern and was never affected; no change there.
•What changes for you — point batch delete and batch export at all your IDs at once again. If a long session had you falling back to deleting or exporting one email at a time, that workaround is no longer needed.