5

I would like to run an SSJS script which makes callouts to a third party system (which sends WhatsApp messages).

As this action will happen frequently I would like to know if there are any limits I need to be aware of? Call out limits, total time, payload etc.

0

Being a separate platform from Salesforce, Marketing Cloud —originally Exact Target— is not ruled by the same governor limits per edition and number of users as a Salesforce Org —You're probably well aware of that.

Specifically about callout limits there is no documentation. I would expect it to be somewhere in the documentation for the SSJS callout capabilities and yet there's none.

Your best shot would either be to contact support or assume there is none. The former would be the safest if you are not able to run stress tests on your journey before going live, of course :)

6

To my knowledge, the following are the limitations:

  1. Callout Limits: Currently there is not much documented, but there is a 'limit' of 2000 SOAP calls per minute. The other consideration is that if your Automation using this script is a huge resource draw, you can see the rest of your Enterprise slow to a crawl and likely will draw the attention of SFMC that may limit or pause your automation until you resolve it.
  2. Time Limit: For SOAP, they list:
Asynchronous operations - 30 seconds
Synchronous operations (not including tracking retrieves) - 120 seconds
Synchronous operations retrieving large sets of data - 300 seconds

  For REST:

120 seconds for non-tracking opertaions
300 seconds for tracking and data retrieve operations.

  Oh and a script activity has a timeout of 30 minutes.

  1. Payload: The max payload for REST is measured in size, not characters and is listed as 4MB. For SOAP it is listed as 5MB. Outside of that limit, the rest of the limitations are on a call by call basis. For instance there is a limit on total amount of rows that you can push into a Data Extension in a single call, etc.

Note the following bullet points listed in the docs (SOAP) to stay within the provided SLA by SFMC:

- Avoid sending a completely rendered email in high-volume or triggered sends.
- Use dynamic content instead of starting a send definition, pausing it, changing the message, and restarting the send definition. This practice delivers inconsistent tracking information, no aggregate tracking data, and adds data rows to your tracking information.
- Avoid using high-volume triggered send calls using the synchronous SOAP API. Consider using asynchronous API calls to reduce server strain.
- Store message content in content areas instead of data extensions.
- Use send logging instead of send-time attributes where possible.
- Restrict the number of synchronous threads in your calls to 20 or fewer.
- Restrict your API requests to 50 objects per synchronous call or 100 objects per asynchronous call.

There is a list of 'Yearly limits' in the documentation, but as far as I know these are not officially enforced yet.

I also found an 'Optimum Thresholds' table. Although I believe it is centered around SOAP API only, I thought it worth sharing:

enter image description here

  • Hey, thanks for sending these details over, they'll be very useful in the future however this doesn't answer my question (apologies it it wasn't clear). My question is around limits relating to making HTTP requests to other service (outside of MC). – Deployment Failure Jan 23 at 15:23
  • 1
    @DeploymentFailure - That is mostly determined by the receiving service. The above are the only restrictions presented by SFMC regarding API. I would say the only thing to be aware of is to ensure resource draw is not too large and that it fits within 30 minute timeout window for Script Activity. Those would be the only major consideration on SFMC side. – Gortonington Jan 23 at 17:52

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.