We want to monitor custom-function failures through the API so we can find and re-run failed functions quickly. We could not find a function-failures endpoint in the API reference (only webhook failures are documented), so we tried the paths that exist on the API and the Zoho CRM MCP tool. All of them return a successful response with no data while the Failures view in the CRM UI lists real failures at the same moment. Because these responses look like success, our monitoring reported "no failures" for weeks while functions were failing.
At the time of testing, Setup > Developer Hub > Functions > Failures (Last 30 Days) listed 13 failures, mostly from one workflow-triggered Deluge function. All calls below were made within minutes of each other.
1. GET /crm/v8/settings/functions/failures
Result: HTTP 204, empty body.
2. GET /crm/v8/settings/functions/{function_id}/failures
- No query parameters: 400 PATTERN_NOT_MATCHED, details.api_name "source". So the endpoint exists and requires "source".
- ?source=workflow: HTTP 200, body {}
- ?source=automation: HTTP 200, body {}
- ?source=xyz (a made-up value): HTTP 200, body {}. An invalid value should be rejected, not answered with an empty success.
- ?source=crm: HTTP 500
3. MCP tool getAutomationFunctionFailures
Result: function_failures [], count 0, status "success". Its description says it can filter by function id, module and date range, but the input schema only accepts page and per_page, so a function_id argument is silently dropped. We saw the same result earlier, on a day when the UI showed 6 failures.
4. For comparison, the request the CRM UI makes for its own Failures view does return the data, with the same OAuth token:
GET /crm/v2/settings/functions/failures?start=1&limit=100&componentType=all&language=deluge&period=last_month
Result: HTTP 200, custom_function_failures with all 13 rows, matching the UI's CSV export row for row. This path isn't in the public API reference, so we'd rather not depend on it.
Questions:
1. What is the supported, documented API for listing custom-function failures (workflow-triggered and standalone)?
2. Can the v8 endpoints above be fixed? If they can't return this data, an error would be far safer than 204 or {}.
3. Could /settings/functions/{id}/failures reject invalid "source" values, and could the valid values be documented?
4. Could the MCP tool getAutomationFunctionFailures expose the filters its description mentions, and return the same failures the UI shows?
5. Is the v2 settings/functions/failures endpoint OK to use until there's a documented alternative?
Has anyone else run into this, or found a documented way to read function failures?