Bulk invoice submission getting blocked need guidance on rate limits and best practice

@Ankit.K.Tiwari @idaoud @Majd_Alawadi
Hello

We are integrating with ZATCA e invoicing API from our ERP system and facing an issue during bulk invoice submission

Our current flow is as follows

A user selects multiple invoices from the system
We generate an array of invoice ids
Then we loop through each invoice
For each invoice we generate XML and submit to ZATCA API
There is no delay between requests
Only API timeout is set to 30 seconds

When the number of invoices is high around 100 to 300 submissions at once we are seeing failures or blocking behavior

We are not sure if this issue is caused by
ZATCA server rate limiting or blocking
or our hosting provider firewall or connection limits since we are using shared hosting and the same IP is used by multiple softwares

We need clarification on the following points

  1. Does ZATCA enforce any rate limits per IP or per taxpayer
  2. Is there any recommended number of requests per second
  3. Is sending many invoices in a loop without delay considered incorrect usage
  4. Is there any guidance for bulk invoice submission from ERP systems
  5. Should we introduce delay or throttling between requests
  6. Is there any recommended architecture for handling bulk submissions

Our goal is to ensure compliance and avoid being blocked while maintaining system performance

Any official guidance or best practices from ZATCA team or other developers would be very helpful

Thank you

What manner of failure do you encounter?

Our cloud-based system serves numerous Taxpayers without issue. Allow me to elucidate our operational protocol: For simplified invoices, an XML file is generated, a requisite step for producing the QR code to be printed on the buyer’s physical copy. We retain this file, and the invoice is subsequently queued for background reporting. The reporting mechanism employs a retry strategy in the event of failure; however, if failures persist and the error code is 503, the system ceases further transmission attempts due to service unavailability. This ensures server resources are not unnecessarily consumed while the service remains inaccessible. A specific algorithm governs the retry process.