I’m using postmark to send a newsletter to my users, and it’s generally great. But I’m having an issue with a backend workflow designed to send a daily newsletter to users. I designed a recursive workflow that searches for the first user who hasn’t received a newsletter that day and sends them the newsletter using Postmark (via the Bubble API connector). It then searches for the next user and so on. Once it has gone through all the users in the database, it reschedules the workflow to run the next day.
The problem that I’m having is that the workflow stops when it tries to send a Postmark email to a user whose email address is inactive (for example, if the user misspelled their email address). Instead of moving on to the next user, it stops altogether. If I look at the workflow logs, I see an error that reads:
"Workflow error - The service Postmark - Newsletter just returned an error (HTTP 422). Please consult their documentation to ensure your call is setup properly. Raw error: {“ErrorCode”:406,“Message”:"You tried to send to a recipient that has been marked as inactive.\nFound inactive addresses: james_ryan11@outlook.con.\nInactive recipients are ones that have generated a hard bounce, a spam complaint, or a manual suppression. “}”
Since I guess this sort of thing is inevitable, does anyone know of a way to prevent the workflow from stopping altogether when this happens? Otherwise it’s hard to see how to reliably set a recursive workflow that uses Postmark to send regular emails to a large user base. Thanks!
This would work great for situations where the error is one user, but I have a couple questions about this.
I often mess up on JSON issues, so if my newsletter is sending to 700 people, and I have his checked will it just keep going and spitting out 700 errors?
Second question, what does “Include errors in response”. What response? Does it send the error to the user, or does it send an email to the admin? Is this just a response in the log?
Every time your app makes a request to Postmark (or to any 3rd party API, or to any of your own backend endpoints) it will receive a response back with a status code, plus usually some other data formatted in JSON. If that status code isn’t in the happy range of 200 - 399 Bubble will avoid you blundering into your subsequent workflow actions and stop the workflow, unless you ask it not to via the checkbox.
If you do check it then it will collect the status code and some JSON describing the issue which you will then need to handle via your workflow. No one will be notified, you just get the chance to handle the issue via your subsequent workflow actions.
When you’re populating JSON with text that you don’t directly control as you are here my strong advice is to avoid building it piecemeal via the API connector.
Unsafe characters can very easily make their way into your request body… This is especially true using 3rd party email services because you’re often passing HTML & Style tags in the mix. When the request body is built with JavaScript it is constructed in a much stricter environment where 100% sure of the unsafe characters are made safe before you attach any value to the body.
So in the case of Postmark you should use @lindsay_knowcode 's Postmark plugin which applies that processing to ensure no baddies get into your JSON. I’m not plugging it, I’m just trying to avoid you the pain - I first looked at this with you probably over a year ago.
If you find yourself constructing JSON like this in a different context and no good plugin is available then you must use Bubble’s :formatted as JSON-safe as it provides reasonable but not total coverage on the potential issues.
