New "hard" rate-limits on API queries from 29 Mar 2012

5 posts / 0 new
Last post
#1 Wed, 28 Mar 2012 11:11
Adam M

New "hard" rate-limits on API queries from 29 Mar 2012

The InterFAX API has had "soft" rate-limiting in place since its inception, as detailed under System Limitations. The "soft" limitation was not enforced until now in the case of the number of queries per minute that could requested from the InterFAX API for outbound fax status and for inbound fax retrieval.

Begininning 29 Mar 2012, InterFAX will impose "hard" rate limits by actively enforcing limitations on calls to the following Web Service methods:

Outbound methods
FaxStatus, FaxStatusEx, FaxStatusXML, FaxQuery, FaxQuery2

Inbound methods
GetList, GetList2.

This means that systems placing more than six calls per minute (subject to change; the authoritative number appears on the System Limitations page) to these methods will receive an error (code -1011), where they now receive a valid reply.

This change may or may not affect your application. Some applications may accept the error and retry the query after a while, while other applications may not handle the error gracefully. You are advised to check how your application behaves.

We are aware that making changes to a production API causes inconvenience to our clients, which is why we forcefully avoid making such changes during the normal course of business. However, in this case, over-usage of our API has in the recent weeks brought our system to a standstill on several occasions, which forces us to perform this change.

To avoid hitting the rate limit, apply the following practices when placing queries:


1. If you have a single outbound fax outstanding: simply query for its status no more than six times per minute.

2. If you have multiple outbound faxes outstanding: query for all faxes at once, for example by using method FaxQuery with the "IN" verb and all the outstanding transaction IDs in "VerbData".

3. If you have more than 100 faxes outstanding, use method 2 above, querying for 100 faxes at a time.

4. If you have no outbound faxes outstanding, avoid querying the Web Service. (Yes, you'd be surprised that some applications keep on querying for faxes when none are outstanding).

5. Alternatively, avoid polling for outstanding faxes and use outbound confirmation callback


1. Use method GetList or GetList2 no more than six times per minute.

2. Even better: avoid polling altogether and set up inbound callback.

Tue, 11 Sep 2012 22:06
Lora (not verified)

>>systems placing more than six calls per minute will receive an error
Could you please specify if the following scenario is still OK for the "6 calls per minute" condition

at 0 sec GetList
at 1 sec GetList
at 2 sec GetList
*** one minute passed
at 62 sec GetList
at 63 sec GetList
at 64 sec GetList

or is there a requirement for at least 10 sec between consequitive calls?
Thank you,

Thu, 19 Jun 2014 12:39
Eyal N

Hi Lora,
Yes - the scenario that you describe here would work fine. The rate limits are per "clock" minute - that is, as soon as the clock starts counting a new minute, the counter of number of requests resets as well.


Mon, 27 Jul 2015 09:49
ugrandolini (not verified)


I'm setting up an application using your services to send faxes.

Following your suggestion I setup the outbound confirmation callback and it properly works.

The page that is called back updates my internal DB using the "TransactionID" as the key to retrieve the original record.


1) is it possible to know a list of IP that I can consider valid so that I will update the DB only if called by your servers?

2) I initially create a new record every time the system is sending a fax; to reference the record I use the "TransactionID" that I get from the "SendfaxEx_2" call; unfortunately as SendfaxEx_2 might return a negative number if something goes wrong, it will be difficult to retrieve the proper record after a SendfaxEx_2 call that goes wrong.
I'm not sure if the "JobID" field is actually handled by your system – in such case I can use the JobID to create a unique reference and will be able to retrieve the proper record in my DB when needed.
Can you please let me know if I can safely use the JobID?


Thu, 6 Aug 2015 21:33
Eyal N

We recommend not to depend on the IP addresses of InterFAX as those may change from time to time and without notice - which could result in the callback requests not reaching your system.

The concept that you listed to store the transaction ID that you receive as the result of SendFaxEx_2 would be my recommended way.
The process would be this:
- Submit a fax using SendFaxEx_2 and store the response (assuming that the response is greater than 0) in your database.
- Receive a callback request and check that the transaction ID in the callback is listed in your database - in which case you will store the data in the callback.
- If the SendFaxEx_2 response is less than 0, then that means there was no fax submitted and so no callback will be sent back to you.

Log in or register to post comments

Contact us today

Talk to a member of our team about the benefits InterFAX can bring to your organization's communications processes.

Contact us today