Best practices: Error handling
The Workflows platform will handle displaying any errors thrown by an API to a connector’s end user. The use of the Error Handling If Error (Try/Catch) function can be limited to special circumstances, like handling messages in a connector’s _authping flow. However, there are some best practices for error handling when designing cards for a connector.
Required input handling
When you're creating inputs for a connector, the Inputs dialog allows you as a builder to mark fields as being required. Setting a field as required means that end users of a connector card need to either enter a value into that field or drag in an output from another card. Because users can drag in output fields to satisfy the card’s frontend validation, there is no guarantee that when the flow executes that output field will contain an actual value. Because of this, it’s good practice for connector developers to verify that required values exist before making a call to an API. This will prevent the platform from sending known bad requests to the API, and will also protect the end user’s API limits.
The simplest way to validate required fields is to use the Error Handling Return Error If card. It is recommended that you use the following format for a required input error message: No <Input Name> input provided. Please enter a valid <Input Name>.
Be sure to include a 400 status code with the message. A 400 Bad Request response status code indicates that the server cannot or will not process the request due to something that is perceived to be a client error (for example, malformed request syntax, invalid request message framing, or deceptive request routing).
Add a Return Error If function to the right of your Connector Action (event) card.
Drag the required input into the value a input of the Return Error If card, and set comparison to is empty.
In the message field, type No <Input Name> input provided. Please enter a valid <Input Name>. where <Input Name> is the display name of the field.
Enter 400 into the statusCode field.
Best practices: Action card names and descriptions