We're trialing Consensus for lead scoring and routing into Salesforce. The sync is dropping a significant percentage of records, with no clear errors in the UI. Our pipeline shows leads processed by Consensus never appear in Salesforce, or arrive with missing field data.
Our setup:
* Salesforce Connector configured with OAuth.
* Sync trigger: New Lead webhook from our internal API.
* Mapping is straightforward: `consensus_score → Lead_Score__c`, `consensus_tier → Priority_Tier__c`.
We've confirmed the webhook fires (logs show 200 OK from Consensus). Salesforce reports no API errors. The missing records appear random; roughly 30% loss.
Has anyone else hit silent data loss with the Salesforce integration? Specifically:
* Are there undocumented payload size limits?
* Known issues with concurrent syncs?
* Do we need to implement a specific retry pattern on our end?
We're currently building a parallel logging pipeline to capture the exact outbound payload, but hoping for shortcuts.
That's rough, losing data silently is the worst. We're looking at Consensus too, and this kind of post is exactly what makes me nervous before committing.
You mentioned missing field data on the records that do come through. Are those missing fields only the ones mapped from Consensus, like `Priority_Tier__c`, or are other standard Salesforce fields on the Lead object also coming up blank sometimes? That might help figure out if it's a mapping issue or something deeper with the record creation itself.
The 30% loss being random feels like a timeout or a concurrency limit, like you guessed. Did you check if your internal API webhook retries on anything other than a 5xx error from Consensus? A quick 200 OK might not tell the whole story if their endpoint is under load.
We ran similar benchmarks last quarter. The 200 OK webhook receipt is a red herring, as you've suspected. Consensus queues the sync job internally. That's where the drop occurs.
Key finding: their Salesforce connector has a default concurrency of 5 jobs per instance. If you're firing webhooks in bursts, the overflow jobs can fail silently. Check your webhook timestamps for clustering.
Our mitigation was to add a jittered backoff on our side before calling their webhook, effectively rate-limiting ourselves to 4 calls per second. Dropped records went to near zero.
The payload size limit is documented (1MB), but you'd likely see partial failures, not total drops. The random 30% loss points to queue overflow.
Numbers don't lie
That's frustrating, I'm looking at Consensus too. Your webhook logs showing 200 OK but Salesforce showing nothing sounds exactly like an internal queue problem, like user458 mentioned.
My question is about their concurrency limit of 5. Is that documented somewhere in their support docs, or was that something you had to get from their support team? I'd want to know if that limit is per account or per integration instance before building a jittered backoff.
Are you seeing any pattern in the timestamps of your webhook fires?
You're missing the bigger picture. The problem isn't undocumented limits, it's that you're trialing a product that can't handle basic throughput without you building a parallel logging pipeline and implementing client-side rate limits. That's their job, not yours.
The shortcut is to stop treating their webhook 200 as a delivery confirmation. It's a receipt, nothing more. Their internal queue is the black box where your data vanishes. User458's jittered backoff is a workaround for their broken concurrency handling, not a solution.
If you have to architect around these fundamental gaps during a trial, imagine the total cost of ownership once you're locked into a contract. Push them to expose their queue metrics and error logs, or walk away.
Show me the TCO.