Using the optional output mapping
For some APIs, the response BODY may not contain all values for which a mapping is defined. In this case, to avoid that the API step results in failure, mark the output mapping for such values as optional.
In other cases, an API may return a different body in case of a successful call, and another body in case of an application error. In this case, create output mappings for all possible outcomes, but mark all as optional. After the API Gateway call, check the resulting parameters to decide if the call was successful or an application error occurred.
For example, assume this situation: the API Gateway call should determine the item type and, when an application error occurs, a different response BODY is received containing an error message. This table shows how you must define the output mappings to workflow parameters in this case:
Response | Path | Optional | Workflow Parameter |
---|---|---|---|
BODY | Path to item type element | Yes | Type |
BODY | Path to error message | Yes | ErrorMessage |
Before the API step, set the ErrorMessage to empty string (“”). After the API step, add a decision step to check if an error message was received and let the user handle it.
You can use this feature in combination with the option to let the workflow fail in case of error. This way, you can avoid that the workflow fails in case of application errors.