Zoho CRM Deluge Error: BIGINT Data Type Mismatch with Lookups

A Zoho CRM Deluge error reporting a "BIGINT data type mismatch" with a lookup means the script tried to write or compare a numeric lookup ID as the wrong type. Zoho stores record IDs for lookups as large integers (BIGINT), and passing a string, null, or an incompatible numeric format triggers this error.

What it means — concrete explanation tied to the Zoho API surface

When a Deluge task or the CRM API updates a lookup field, the engine expects the lookup value to be the module record ID (a BIGINT) or an object that includes that ID according to the API payload shape. Supplying a string, an empty value, a composite object without the numeric "id" key, or a number outside the BIGINT range causes the CRM layer to reject the operation with a data type mismatch ^[3].

Common causes

• Passing the lookup record's display name, email, or custom field value instead of the numeric record ID ^[3].
• Sending the ID as a quoted string (e.g., "123456789012345") instead of a numeric type in Deluge or API JSON ^[3].
• Using an empty, undefined, or null variable in the lookup field when the API expects a valid BIGINT ^[1].
• Constructing the lookup object incorrectly (missing the "id" key or wrong JSON structure) when calling /crm/v2 or using zoho.crm.update record calls ^[3].

How to fix it

1. Confirm the source value is the numeric record ID: fetch the related record via getRecord or a search call and use its "id" property. For example, use response.get("id") rather than response.get("Name") in Deluge ^[3].
2. Ensure the ID is numeric in the payload: in Deluge, do not wrap the ID in quotes; in REST calls, send it as a number or as {"id": 123456789012345} inside the lookup field.
3. Build the lookup object exactly as the API expects. For a record update in Deluge: map.put("Account_Name", {"id": accountId}); then call zoho.crm.updateRecord("Contacts", contactId, map) ^[3].
4. Add defensive checks: if (accountId == null || accountId.toString().trim().length() == 0) then skip the lookup update or raise a clear validation error instead of sending a blank value ^[1].
5. Reproduce with a minimal payload: send only the lookup field and ID to the API to confirm that the BIGINT error disappears, then expand to full payload once fixed.

When to escalate

If you confirm the code sends a numeric "id" and the CRM still rejects it, collect the failing request body, response headers, record IDs, and timestamps and open a ticket with Zoho Support. Include the minimal reproducible script and API call so engineering can inspect type coercion at the service layer.

^[1]: Zoho Community posts about CRM scripting and related list integrations.

^[3]: Zoho Community thread discussing API behavior and Deluge script interactions.