Troubleshooting Custom Field Updates in HighLevel via HTTP Request PUT

It appears your topic is missing some crucial details. Could you please provide the following information, if relevant?

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

Please share these details to help us understand your issue better.

Hi, welcome to the callin.io community and thank you for your question!

You mentioned the following parameter was reported 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, please 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!

There are a couple of threads regarding the HighLevel node and custom fields. These are likely related, and I suspect the team hasn't reviewed these posts yet.

Thanks for sharing that. 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.

Are there any updates regarding this issue?

I'm unable to create any new workflows because of this, and my work has been halted until it's resolved. Another user is also waiting for this to be fixed.

I'm also encountering the same problem after switching to the HighLevel API v2.

The HL node requires a revision and potentially the reintroduction of its v1.

HL has now launched Private Integrations, which utilize an API key, and this functionality needs to be incorporated.

Are there any updates or progress on this matter? If it's expected to take some time, could the v1 HL node be temporarily reinstated? The v1 API is still operational, although it's no longer officially supported. This would allow us to use the node properly and run workflows while a resolution is being worked on.

I've utilized the HTTP Request node as a temporary solution. Hopefully, this can assist you until the issue is resolved?

image422×818 34 KB

Here is the complete JSON, as I'm still new to this and believe it might be helpful:

json
{
"customFields": [
{
"id": "",
"field_value": ""
}
]
}


Yes, I'm also using this as a temporary solution. Moving forward, new API keys will function as bearer authentication tokens with V2.

Therefore, we require a node that supports the complete OAuth method, as well as a node with a method akin to v1 for the Private Integrations approach using bearer tokens.

Given that authentication methods vary based on different scenarios, we might not always have complete OAuth access and may only receive an API key. This necessitates support for both methods.

From the GHL development team:

You can utilize the Private Integration Token as Bearer Authentication for all Location-level APIs, similar to how you currently use OAuth Access Tokens. This functionality is exclusive to API v2.

Therefore, we require a method to employ the OAuth v2 API using only an access token, without the necessity of configuring a Client ID, Secret, or Scope.

Please advise on how to achieve this.

Can anyone offer an estimated timeline or confirm if this issue is under active development or in the queue?

There are bug reports on GH from last week that have already been resolved, yet this problem has persisted for a month.

EDIT - I've just discovered an older workflow utilizing the v1 node that is still functional and successfully retrieves custom fields in the search box.

It's possible there's a discrepancy in how v1 and v2 fetch custom fields from HL.

CleanShot 2024-07-24 at 17.34.39@2x582×904 19.4 KB

Hey,

One of the challenges we're facing is obtaining a test account, as there doesn't seem to be a method to find a contact email address for anyone.

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

Thanks Jon,

I've reached out to the HL developers to see if there's a way for you to connect with them. They do have a Slack channel, and we're exploring if they can provide a test account to assist with the integration.

In the event that's not possible, I can offer you a sub-account on my test environment. However, I don't believe you'd have direct access to their support channels in that scenario.

Hey,

The Slack integration would be very handy. I've just found the link on their page that I somehow missed before.