My first thought would be to rebuild the webhook step in a custom action on their developer portal where you have more control. From there you can have Zapier throw halt errors or configure a custom message when the file doesn’t exist. 

he UI builder is not much more difficult than configuring the webhook action! https://platform.zapier.com/docs/zapier-intro 

Halt errors: https://platform.zapier.com/cli_docs/docs#halting-execution 

Alternatively, if the webhook isn’t what is throwing an error and stopping the zap but rather an action that was dependent on the result returned. You can always place a filter directly after the webhook to only continue the zap if the dependent field is returned/exists. 

Let me know if you need more help!

Thanks!
 

@GetUWired in this case you are suggested I create my own Zapier app and use their interface to make the web hook? If so, wouldn't this make the app public to everyone on Zapier? 

In regards to your last part, correct. The error is not stopping the zap. However, I cannot use the Webhook Zap to create lets say a path based on the error response from the file systems API.   If only I could say, if error is returned, go through path B if not, go through path A. Or something along those lines.

@quickjeff - A custom integration is by default private. Even if multiple users are using it, their authentication data will be isolated from each other.

@quickjeff 

What does it look like when the error is returned? Have you tried to set up your paths for when an error is returned? 

You could also set up you path for a specific field that is always returned on a successful response. I.e. if ID is “exists” go down path A. If ID “does not exist”, go down path B. The end result would be as if you’d set it up to look for an error but with the inverse logic.