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.
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.
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.
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
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
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
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
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