Custom Fields Update in HighLevel Using HighLevel Node or HTTP Request PUT Not Working

Describe the problem/error/question

When I initiate update of any custom field for a contact in High Level using the High Level Node, I get the error messages:

Problem in node ‘HighLevel‘: Your request is invalid or could not be processed by the service

Parameter: “additionalFields.customFields.values[0].fieldId” has issues

If I change the update to the standard fields, everything works well.

If I use HTTP Request node instead of the HighLevel node, update occurs only on certain fields, and not on any of the custom fields even though the output test reports successful update.

Information on your n8n setup

  • **n8n version: 1.46.0
  • **Database: SQLite
  • **n8n EXECUTIONS_PROCESS setting: own, main
  • **Running n8n via: n8n cloud
  • Operating system:

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:

Hi @austinemarie, welcome to the n8n community and thank you for your question!

You mentioned the following parameter was mentioned as having issues, but I don’t see that anywhere in your shared workflow. Did you use that as the parameter for identifying your custom field in the first Highlevel node?

If so, double check that you aren’t setting that as a fixed value, because I see a couple of other fields that are fixed and should be expressions in your Highlevel1 node.

Hope this resolves your issues - happy building!

@Ludwig there are a couple of threads about the HighLevel node and custom fields.

Most probably related and I guess the team haven’t seen these posts yet

1 Like

Thanks for sharing those @gleeballs I’ve created an engineering ticket with my team to allocate time for a fix. We’ll update all cases when a fix is released.

1 Like

@Ludwig don’t suppose there is any updates re this is there.

I cannot make any new workflows due to this and it has put my work on stop until this is resolved. @paulugwuanyi is also waiting.

also getting same issue since swapping over to the highlevel API v2

The HL node needs an overhaul and possibly bring back v1 of the node.

HL have now introduced Private Integrations with an API key so this needs to be implemented too

@Ludwig Is there any updates or progress for this? If it is going to take a while, can we not have v1 of the HL node brought back temporarily as v1 of the API is still in use just not supported. We can at least then use the node properly and be able to run workflows until it is resolved

I’ve used the http request node to work around it at the moment. May help get you out of the pickle until its fixed?


image

Here’s the full json as I’m still new to this so know this would have helped me

{
“customFields”: [
{
“id”: “”,
“field_value”: “”
}
]
}

Yeah also using this as a workaround for now but going forwards there are new API keys that work as bearer Auth tokens with V2

So we need a node that will allow the full oauth method and also a node with method similar to v1 that we can use for the Private Integrations method using bearer tokens

As there are different Auth methods depending on different use cases, we may not have full access to oauth and just get an API key so we need both

1 Like

from GHL devs:

You can use the Private Integration Token as Bearer Auth in all Location level APIs - Just as you do with OAuth - Access Tokens today. This works with API v2 only

So we need a way to be able to use OAuth v2 API with an access token only and not having to set a Client ID, Secret or Scope

1 Like

Is anyone able to provide a rough eta or confirm if this is being worked on, or in the process queue.

There are bugs on GH that have been reported last week that are already fixed whereas this is going on for a month now?

EDIT - Just found an old workflow with the v1 node which is still working and grabbing the custom fields in the search box.

Perhaps there is an error between how v1 and v2 retrieves the custom fields from HL

CleanShot 2024-07-24 at 17.34.51@2x

Hey @gleeballs,

Part of the problem we have is getting a test account as there doesn’t appeat to be a way to actually find a contact email address for someone.

I will however add this to my list of issues to resolve next week.

Thanks Jon,

I have asked the HL devs to see if there is somehow you guys can contact them, they do have a Slack, and if they can provide a test account for help with the integration etc.

Worst case, I can give you a sub-account on my test account but I don’t think you would have direct access to support

Hey @gleeballs,

The Slack would be very handy, I have just found the link on their page that I somehow missed before.

Any update for the issue?

This is still not working?

This is next in my queue to pick up.

1 Like

It would be great if the node could be updated at the same time to support Private Integrations.

Basically back to the old way of using an API key rather than OAuth which could be easier as OAuth was a bit funny at times.

Private integrations is more powerful as it uses the v2 api and is more flexable than the OAuth method as it is much more easy to implement and to close off in the sub accounts

Just wondering if there was any updates to this.

Either getting the custom fields working again and getting private integrations implemented?

Or can we get the v1 of the node back as that worked