HighLevel node

Hi, I am currently running a self-hosted version of n8n and I am trying to build an app using the Highlevel node. It seems that there’s an issue with the node parameters, especially the ‘Custom Fields’ parameter. I have attached a screenshot for context. Even when the dropdown button never loads and I specify the field ID, I still get an error. For context, I am on version 1.45.1. I am also scared to update as I do not know how to back up my credentials and workflow data yet. But that’s a different concern for another time. I just need help with the HighLevel node.

It looks like your topic is missing some important information. Could you provide the following if applicable.

  • n8n version:
  • Database (default: SQLite):
  • n8n EXECUTIONS_PROCESS setting (default: own, main):
  • Running n8n via (Docker, npm, n8n cloud, desktop app):
  • Operating system:

I’m using PostgreSQL and am running via Docker on an Ubuntu system


…when I try to manually drag a custom field into the parameter query tab.

getting the same errors too - HighLevel Custom Fields not working

I am on 1.47.0 so if its across multiple versions, I wonder if its something on the backend or HL API related

It’s pretty frustrating especially as HL has switched from the API v1 to OAuth. Glad I’m not alone on this at least

You can still use the API key mode, it just that n8n has removed that node as far as I can see. I have it working on an old workflow with old node via API key, can’t add new HL nodes and use with API key it seems

EDIT - i think you can create a HL credential and use the API method, but there is no way to use that within the new HL node and test to see if it works or not.

Tried a few instances and various versions and all having the same issue so seems to be an n8n issue or HL API issue or just HL issue.

Yeah, I have a credential I created with the API v1 key. However I cannot use that credential in the new HL node. That method has been depreciated it seems. I’ll keep monitoring your conversation with Mariana to see if she’s able to find a resolve from her side HighLevel Custom Fields not working.

Also, how did you get it to work using the HTTP request node? Also, it seems even that method won’t solve the ‘Custom Field’ malfunction :man_shrugging:

It would be good if we could still have the option of using the v1 node with API key.

You need to turn off the Enhanced Account Security in your Agency Settings > Company > Bottom of page.

This will let you continue to use the API key method with v1 of the HL API

For the HTTP nodes. To get the custom fields from a location use the below:

GET/v1/custom-fields/

and to update the custom field values use the below:

PUT/v1/contacts/:id

Thats how I have it working at the moment. Not ideal as it is using v1 of the HL API which is EOL now but it works until the v2 node is fixed

I see how it works. Interesting. My only thing is that the Custom Field that’s to be updated must contain data else the Get request won’t pick it up.

The initial custom fields GET request will get all the custom fields from the location and list them in an array whether they have a value or not - it is just getting the field data - name, id, key etc.

At this point in my workflow, all the custom fields have no saved value/data

When updating them using the contact PUT request, you can edit the body json to only update the custom fields that you want with the value that you want

{
“email”: “{{ $(‘Webhook’).item.json[“body”][“email”] }}”,
“phone”: “{{ $(‘Webhook’).item.json[“body”][“phone”] }}”,
“source”: “public api”,
“customField”: {
“{{$(‘Get Custom Fields’).item.json[“customFields”][4][“id”]}}”: “{{ $(‘Doc’).item.json[“output”] }}”
}
}

in the above, i am only updating 1x custom field - [“customFields”][4] (from the initial GET request) - with the output data from Doc node.

I have 14x custom fields in this location

1 Like

…still waiting for feedback from the n8n team.

Any update about the troubleshooting?

So I got in touch with a member of the team and they’ve been working on fixing a lot of bugs on the app. I haven’t updated mine yet to see what changes have been made since. But I found a workaround that I was content with. I webhooked (not a real word but we move) the data from n8n out to Make.com. I am on the free tier on Make.com so this worked fine. Inside my Make workflow, I’d listen for any calls

2 Likes

this is good news - hopefully private integrations is included in the updates as it is a much better auth system that oauth at the mo :crossed_fingers:

1 Like

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.