Troubleshoot API calls using the guidance provided in the following sections.
Why isn't my API call working?
Use Audit History to troubleshoot API problems, as follows:
- Open your app in the editor.
- Go to the Manage > Monitor tab and expand Audit History.
- Click Launch log analyzer.
The Audit History log displays.
- Look for audit records with an
REST API invoke.
Note: You may need to wait for up to five minutes for an audit record to appear in Audit History. AppSheet groups audit records and periodically writes the grouped audit records to reduce overhead. This can result in a delay before an audit record appears in the Audit History. Click Get audit history records periodically until you see the audit record.
- Click the Details icon to see the outcome of the API call.
- If the API call failed, the Details provides the reason for failure.
- If you see
"Result": "Success"at the end of the audit record, then the API call succeeded.
Error: Row having key not found
Row having key '<key value>' not found indicates that the record with the specified key could not be found when performing an update or delete. This can occur if your table has a security filter that excludes the record.
The REST API request runs under the user ID you specify in the REST API
UserId property. If no
UserId is specified, the REST API request runs under the User ID of the app owner. See Invoke the AppSheet API.
Error: Value cannot be converted to type
Value '<value>' in field '<field name>' cannot be converted to type '<type>' indicates that the data value in the field is invalid or is not in the expected format.
The Locale property is used when validating
Price data values. For example, when
en-US, date values must be entered in
MM/DD/YYYY format. When Locale is
en-GB, date values must be entered in
DD/MM/YYYY format. When no
Locale is specified,
Locale en-US is assumed and date values must be entered in
Error: AppSheet Webhook action depth reached
AppSheet Webhook action depth reached indicates that an automation webhook is attempting to invoke the REST API repeatedly and has reached the recursive calling depth limit of 5.
This error typically arises in the following circumstance.
- The application contains an automation bot that invokes a webhook that calls the REST API to add, update, or delete one or more records in a table.
- When the REST API is called, it adds, updates, or deletes the appropriate records. It then triggers any events associated with those records. This may include events that invoke a webhook that calls the REST API. This can lead to intended or unintended recursion.
- Unintended recursion occurs when a webhook calls the REST API, which triggers a webhook that calls the REST API, which triggers a webhook that calls the REST API, and so forth indefinitely. This is a form of infinite recursion. To stop infinite recursion, AppSheet maintains a counter to detect and prevent it. When the calling depth limit of 5 is reached, AppSheet displays the error
AppSheet Webhook action depth reachedand prevents further recursion.
Add or update of an EnumList field reports "failed Valid_If condition"
If you Add or Update a record having an
EnumList field, the Add or Update may fail with the error:
"Error: Row having key '<key value>' in table '<table Name>' containing value '<enumList field value>' failed Valid_If condition"
This happens when the
EnumList field specifies a
Valid_If expression containing a list of valid values. If you attempt to store a record containing two or more values in the
EnumList field, the
Valid_If condition will fail. This is the result of a long standing shortcoming in the server expression system.
For example, the
EnumList field might specify the
LIST("A", "B", "C", "D")
The system automatically converts that
Valid_If expression into the following equivalent
Valid_If expression. Note that
[_THIS] refers to the value of the current field; in this case, the
IN([_THIS], LIST("A", "B", "C", "D")
When the server expression system evaluates the
IN() expression, it fails to detect that the
EnumList field may contain a
LIST() of values. It mistakenly treats the value in the
EnumList field as a single value which it compares to each value in the
LIST(). For example, if the
EnumList field contains
"A , C", it compares
"A , C" to the
"C", and finally
EnumList value "A , C" does not match any of these values, so the
Valid_If condition fails.
Note: We are investigating how to fix this shortcoming in the server expression system. This is more difficult than it seems because we need to fix the problem without breaking customers who may be advertently or inadvertently relying on the current behavior. We are not aware of any way to avoid this problem other than removing the
Valid_If expression for the