Hello @amir_naderi, hope you are doing alright. 

Are you having same response when running the requests directly via GraphQL? This would be recommended to test your queries and the response given. 
Also, it´s important to check if you are not reaching the request limit of your plan.

In additional, I’d like to share additional information that might help you troubleshooting the errors

https://developers.pipefy.com/reference/status-and-error-handling

Hope this can help you. 

Hello @amir_naderi ,

I use Make and occasionally I get these returns, but in all cases so far, it was the data I was trying to pass via API that was wrong.

Please note:
- Format of the information you are trying to save is the same as the field format
- Information you are trying to save in the field available in the selection list (when the field is a list)
- Limits of your automation plan
- Field ID identical to Pipefy ID

Thanks for the suggestion on testing via GraphQL—I hadn’t thought of that approach, but I’ll definitely incorporate it into my testing process. What I should’ve mentioned earlier is that when I get these errors, I rerun the job about a minute later, and it usually works fine, which makes me think it’s server-related at the time of the initial run.

Also, appreciate the link to the error handling guide. I’m planning to add some error handling to automatically retry the job a few times before requiring manual intervention. Thanks again for the help!

Thanks for the follow-up, Lucas. I’m seeing similar behavior, but what’s interesting is that if I rerun the job about 30 seconds later, it usually goes through without any issues. I’ll definitely keep an eye on the data formats and field IDs, though—appreciate the advice!

@amir_naderi 

If they are specific errors such as timeout or other unidentified errors, you may be able to resolve them with error handling. I don't know how it works in other integrations, but in Make it is possible to handle them in several ways.

I normally use BREAK, which pauses the automation for X seconds (your choice) and executes Y attempts after each BREAK cycle. With this handling, it is very rare for my scenarios to give errors that stop the automation completely.

@amir_naderi

If they are specific errors such as timeout or other unidentified errors, you may be able to resolve them with error handling. I don't know how it works in other integrations, but in Make it is possible to handle them in several ways.

I normally use BREAK, which pauses the automation for X seconds (your choice) and executes Y attempts after each BREAK cycle. With this handling, it is very rare for my scenarios to give errors that stop the automation completely.

 

 

I like your style!

🥷@amir_naderi 

Did this treatment exist before or did you do it now?

Has it been working since then?

I assume it was there, I was just oblivious to it, lol---I have not seen the issue persist on recipes I created this error handler on but on other recipes, yes. I have like 400+ recipes on workato, so adding the error block as I see them;)
Workato actually has a global way of handling errors “recipe ops”, whereas you can create a general rule (ex: if you see a 504 error, retry the block three times) but not avail on the pipefy embedded version unfortunately. 

When investigating API integration issues across platforms like Zapier, Workato, and Pipefy, it's essential to assess the compatibility and consistency of API responses. These tools rely heavily on seamless communication between various software applications Names Hustle, and discrepancies in data formats, authentication methods, or rate limits can cause significant disruptions. Start by examining the API documentation for each platform to identify any potential conflicts or limitations. It’s also crucial to monitor the error logs and response codes to pinpoint where the integration is breaking down. Collaboration with the support teams of each platform may be necessary to resolve any inconsistencies, ensuring that data flows smoothly across all integrated systems.