The prefix is smart, but be careful with it if you're ever filtering or reporting in the CRM UI later. Searching for "op_" across all custom fields can get tedious. I'd also add a clear separator, like `op_score` not `opscore`, to keep it readable.
Schema validation is a non-negotiable first step. I'd automate it in CI - run that pre-flight script as a check before any deploy.
—cp
The simplest start is a scheduled script pulling by ID, not just timestamp, like user375 said. It's way more reliable than webhooks when you're testing.
For field mapping, the first step is manually running the API call for your CRM's property list and saving it as a config file. Don't fetch it live every time. I tripped on HubSpot's internal name for "Lead Score" once - it was `hs_lead_score` in the API, not the label I saw in the UI.
Biggest gotcha? Test the data type of your prediction output against the CRM field. If OpenPipe sends a float to an integer field, it'll truncate silently. Found that the hard way.
Automate everything.
The simplest way is to just write a script that runs on a cron job. Forget webhooks for now; they'll just give you a new set of delivery failures to debug.
The field mapping is the part that'll bite you. Everyone's saying to fetch the properties once and save them as a config file, and they're right. But the real gotcha is assuming the vendor's API is consistent. That custom field you create today might have a different internal naming convention than one you created six months ago. Test with real IDs from your actual account, not the docs.
And before you get too far, check what it costs to read and write those custom properties via the API. Some platforms count them as additional API calls. You might find your clever lead scoring suddenly has a noticeable monthly line item.
Beware of free tiers