David R.

These appear to be mostly Clay -> Slack, which is great, but is effectively what your Slack Approval tool does

Thanks Claybot, answer 1 is closely aligned - though the clay university piece is now offline and didn't provide outbound webhook instructions from Slack.

Awesome - though I'm assuming that comes with the very reasonable caveat that since this goes through 3rd party apis, that can't always be the case, but you're gonna try to deprecate responsibly, gosh darnit.

Appreciate you flagging this Hari K.. Does this mean that previous workbooks using Upsert may now no longer operate (or operates as one and not the other)? Is there some sort of monitoring / alerting in the case where a action starts failing like that?

Seems very similar to this thread: https://clayrunhq.slack.com/archives/C025KSBLPGX/p1746138615044139

Is there any way to disable any JSON formatting magic going on for a HTTP request?

I'm also getting something similar when I try to use the HTTP API to add a record to a list.

I've just started to do the workaround of batch loading records to get IDs then having a subsequent individual record lookup to get associated properties. Working pretty well so far, though I do wish the pattern were more self-evident. Meanwhile for newly loaded contacts: I think the best course of action is to just have a Hubspot Workflow flip their status.

Awesome; thank you for the confirmation on creation. Would you happen to know about the visibility of the hs_is_marketable_status property or the various Hubspot/Salesforce sync properties, particularly from the Bulk Load operation (e.g. when initially populating the table using the Explorer+ tier integration)? On Contact that would be:

salesforcedeleted
salesforcecontactid
salesforceaccountid
salesforceleadid
salesforcecampaignids
salesforcelastsynctime

On Account that would be:

salesforcedeleted
salesforceaccountid
salesforcelastsynctime

On Deal that would be:

salesforcedeleted
salesforceopportunityid
salesforcelastsynctime

(Unfortunately I don't have visibility into the salesforce properties of the Lead model). Here's why this matters: it is of vital importance when using both Salesforce and Hubspot together to know if a Hubspot record is also syncing with a corresponding record in Salesforce. A shocking number of organizations will use Salesforce for their sales teams and active customer account management, but rely on HubSpot for tracking marketing activities (unfortunately this includes my organization). Hubspot maintains a record for ALL contacts, but will treat records in Salesforce as sacrosanct by default if it also exists there. More specifically, if a record exists in Salesforce, then there is a populated value for that field. The HubSpot UPDATE APIs will accept the change and then automatically revert back to the state in Salesforce. Clay (and the user) would get no notification that this field reversion happened. Knowing ahead of time means the builder of the Clay workflow could decide to: