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 Manage > Monitor and expand Audit History.
- Click Launch log analyzer.
The Audit History log displays. - Look for audit records with an
Action
value ofREST 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
The error 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
The error 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 Date
, Time
, DateTime
, Decimal
, Percent
, and Price
data values. For example, when Locale
is 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 MM/DD/YYYY
format.
Error: AppSheet Webhook action depth reached
The error 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 reached
and 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 Valid_If
expression:
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 EnumList
field.
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 LIST()
values "A"
, then "B"
, then "C"
, and finally "D"
. The 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 EnumList
field.