5

I'm aware from the docs that

"A single Apex transaction can make a maximum of 100 callouts to an HTTP request or an API call."

Is anyone aware if that limit is higher in a future methods or queueable apex? Generally, limits are relaxed in an asynchronous context with apex, but I can't find anything talking about callout limits specifically.

I need to make this callout from a trigger, so it looks like future or queueables are my only options.

  • Your trigger would need to break the callouts into blocks that are less than 100 callouts per future method. – crmprogdev Apr 26 '18 at 16:56
  • but how do you process each block once the future method is called? – Tyler Zika Apr 26 '18 at 19:13
  • The code that processes the callouts needs to be moved "into the future" along with the actual callouts. You'll want to write your blocks to a temporary object for processing, then use another trigger (after insert of the blocks) to call queueables that can make the callouts for you. As each one is made and you get a return, access the data in your temp object that needs processing. Mark each record complete upon success & keep track of failures. There's a pattern for this type of thing you'll need to follow. – crmprogdev Apr 26 '18 at 20:01
8

I quickly wrote a class with future method to test this behaviour.

public class FutureClassLimitsTest {

    @future(callout=true)
    public static void docallouts(){

        for(Integer i=0;i<200;i++){
            Http http=new Http();
            HttpRequest hr=new HttpRequest();
            hr.setMethod('POST');
            hr.setEndpoint('https://google.com');
            http.send(hr);
        }


    }

}

This is the error I get. enter image description here

First error: Too many callouts: 101.

So I believe this is uniform for the whole platform irrespective of the transaction(Sync or Async).

Is there a workaround?

Well unless there is a strong business requirement it is kinda bad doing so many callous in a transaction.

We can call a Queauble Method from Queueable method,.. and you can chain them infinitely. Thus using proper implementation you can have 100+ callouts. Batch is another way to tackle this. You have to write /modify data model add a some queue custom SOBJECT to handle your problem.

No limit is enforced on the depth of chained jobs, which means that you can chain one job to another job and repeat this process with each new child job to link it to a new child job. For Developer Edition and Trial organizations, the maximum stack depth for chained jobs is 5, which means that you can chain jobs four times and the maximum number of jobs in the chain is 5, including the initial parent queueable job.

Source: https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_queueing_jobs.htm

  • what I don't like about queueable apex and chaining is I need a separate queueable class for each chain: firstJob(), secondJob(), thirdJob(), etc. I need to make a callout for each record that triggers the trigger. So if 1000 records trigger the trigger, how would I make 1000 callouts? Create 10 queueable classes so I can chain them? – Tyler Zika Apr 26 '18 at 19:46
  • @TylerZika You don't need "ten classes" to chain ten times. I've written a single batch class that handled a dozen different integrations at once called from any trigger that we used. You might want to ask a question that attacks this problem directly instead of what you presented in this question (in other words, you've a bit of an X-Y problem. – sfdcfox Apr 26 '18 at 20:05
  • @sfdcfox isn't it bad practice to fire a batch from a trigger? – Tyler Zika Apr 26 '18 at 20:06
  • @TylerZika The actual mechanism was written before Queueable was a thing; the actual implementation simply wrote to an Integration Log record, and a scheduled class kicked off a Batch job hourly that would process as many integrations as it could in that hour. As a Queueable, this would have been quite a bit more efficient, but I had to work with what I had. My main point is that you can certainly handle multiple callouts in a single class. – sfdcfox Apr 26 '18 at 20:08
  • @sfdcfox fascinating. My process needs to make the callout within minutes after the trigger fires. – Tyler Zika Apr 26 '18 at 20:13
3

tl;dr: The limit of 100 http callouts is the same for all transactions (be they synchronous or async).

The answer here resides in another piece of documentation: https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_gov_limits.htm

Salesforce gives us a semi-visual representation of which limits apply to both sync and async transacttions, and which ones have different limits for sync vs async. As I'm waiting for sfdx to do a large push, I'll try to capture the formatting of that document here.

+----------------------------------+--------------------------+--------------------------+
|           Description            |       Synchronous Limit  |      Asynchronous Limit  |
+----------------------------------+--------------------------+--------------------------+
| Total number of SOQL             |                          |                          
|  queries issued                  |      100                 |      200                 
|
| Total number of                  |                                                     
|  records retrieved
|  by SOQL queries                 |                      50,000                         
|
| Total number of records          |                                                     
|  retrieved by                    |                                                     
| Database.getQueryLocator         |                      10,000                         
|
| Total number of SOSL             |                                                     
|  queries issued                  |                      20                             
|
| Total number of records          |                                                     
|  retrieved by a single           |                                                     
|  SOSL query                      |                      2,000                          
|
| Total number of DML              |                                                     
|  statements issued               |                      150                           
|
| Total number of records          |                                                     
|  processed as a result           |                                                     
|  of DML statements,              |                                                     
| Approval.process,                |                                                     
| or database.emptyRecycleBin      |                      10,000                         
|
| Total stack depth for any        |                                                     
| Apex invocation that recursively |                                                     
|  fires triggers due to insert,   |                                                     
| update, or delete statements     |                      16                            
|
| Total number of callouts         |                                                     
|  (HTTP requests or Web services  |                                                     
|  calls) in a transaction         |                      100                          
|
| Maximum cumulative timeout       |                                                     
| for all callouts (HTTP           |                                                     
| requests or Web services calls)  |                                                     
|  in a transaction                |                      120 seconds                   
|
| Maximum number of methods with   |                                                     
|  the future annotation           |                                                     
|  allowed per Apex invocation     |                      50                             
|
| Maximum number of Apex jobs      |                                                     
| added to the queue with          |                                                     
| System.enqueueJob                |                      50                             
|
| Total number of sendEmail        |                                                     
| methods allowed                  |                      10                            
|
| Total heap size                  |      6 MB                |      12 MB               
|
| Maximum CPU time on the          |                          |                          
| Salesforce servers               |      10,000 milliseconds |      60,000 milliseconds |
|
| Maximum execution time           |                                                     
| for each Apex transaction        |                      10 minutes                    
|
| Maximum number of push           |                                                     
| notification method              |                                                     
| calls allowed per Apex           |                                                     
| transaction                      |                      10                             
|
| Maximum number of push           |                                                     
| notifications that can be        |                                                     
| sent in each push                |                                                      
| notification method call         |                      2,000                          |
+----------------------------------+--------------------------+--------------------------+

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.