Skip to main content

Today all errors are categorized as ‘Errors’ or ‘Critical’ (Critical is only when the page is disconnected or blocked, as far as I know.

There are some errors that are categorized as ‘Errors’ that should not be ‘Errors’.

For example, failed JSON Mapping.

With more AI + Integrations we’re using External Requests more and more, and failed JSON Mappings are, in most cases, by design, and not an error at all.

With all JSON Mappings categorized as errors, it becomes difficult/impossible to find true critical errors.

I suggest:

  • Re-categorizing JSON Mapping errors to ‘Warning’ or Info’ level
  • Ability to filter Critical/Error/Warning/Info messages
  • Keep ‘Error’ category for true errors (5xx, 4xx, invalid content, etc). Basically errors that we cannot catch in our automations using conditions/user fields.
  • Bonus points: ability to filter by type of error.

 

 

Hi Gustavo!

 

Roman from Manychat Support here,

 

Thanks for bringing this up - you've made a really valid point! Right now, Manychat doesn't fully handle scenarios when certain JSON fields are missing from an API response. Ideally, an API contract would always be strict, but practically, we understand that's not always the case, especially with more dynamic integrations using AI or External Requests.

From a technical standpoint, the current Manychat logic is:

If the API response explicitly returns a field with a null value, the corresponding custom field gets cleared in Manychat.

But if the response doesn't include the field at all, no action is taken, and the custom field remains unchanged.

Given your current setup (as far as we can see), it looks like you're explicitly clearing all fields' values anyway. As a workaround, and potentially simplifying your flow, you might consider adjusting your parseJson.php endpoint so that it returns all non-relevant fields with a null value, rather than omitting them. That way, Manychat will clear these custom fields automatically, and you may not need the additional public API request to erase these fields manually.

As for your original suggestion regarding error categorization and filtering, it's a great idea! It would indeed help with clarity and more precise debugging, especially when working with complex integrations. I've made sure our team is aware of this, and your insights will definitely be taken into consideration as we continue improving the platform 🙌

 

Hope this helps! 😊

Thanks for looking into this ​@Roman Raizink !!

Thank you for your suggestions, I’ll most definitely take them into account from now on!

There are some scenarios that still won’t be covered (for example when the response has list items), but your suggestion should clear a good part of the messages! ;)

And yes, categorizing and filtering would help a lot!

Thanks again!!

Gus

Community Terms & ConditionsCookie settings