Why is the Salesforce Connector Making Excessive API Calls and Causing Rate Limiting Issues?

This topic was automatically generated from Slack. You can find the original thread here.

Salesforce connector making a huge amount of API calls. I’ve set up a Salesforce connector which I am using as a source. It’s set to run every minute to get field history changes. Instead of the expected ~1 request/min I’m getting multiple requests per second hitting the Salesforce API and causing me to get rate limited:

In the source logs I can still see one outgoing request per minute. I’m very confused why the API usage is so high.

Hi , would you mind sharing specific Salesforce trigger that you’re using?

Thanks, let me try to reproduce your issue and get back to you

, in the mean time, would you mind trying the instant source?

I though that was the instant source

It wouldn’t have the Timer if it was Instant source. Would you mind trying to create the Instant source?

Okay, I will try that

I cannot create an Instant source in Salesforce:

Thanks , I will share this with Pipedream Component Dev to check further

Thank you

This is still an issue. We are getting rate limited like crazy. I don’t know why Pipedream is hitting the SF so much. We are only monitoring one object and one field.

I’ve had to disable all our Salesforce sources and workflows, as it’s affecting our other automations.

hi , I’m so sorry for the late response.

Per checking the component code, I see that it do 2 more API calls for each record that has been updated. This is the logic to ensure that the event showing on Pipedream is correct and has all the data you need. I’ve pinged the Pipedream component dev to see if how we can improve this logic, I’ll let you know ASAP when there’s new update

Thank you It seems to become problematic when processing bulk updates. The field history query method returns too many IDs and when pipedream tries to query for them all in one go I think it’s too many connections for SF to handle at once. This process needs to be improved, and maybe queued so that no more than X connections are made to SF at any given time.