Dear @Ankit.K.Tiwari ,
We think the issue is not resolved. Getting timeouts still.
Dear @Ankit.K.Tiwari , this Issue is not resolved. Still getting timeout.
Thank you @anusv @itsmeali7978 @Abhishek @hani for confirmation, this is communicated with concerned teams.
Appreciate if others can please try and provide feedback @yamanhusari @dev.cksatc @paganapathy @sameer @saqeralmuntser @EslamSamiH @AhmedGalal @ismailme33 @githin @prakash.sathyamurthy @muneera_salah
@Ankit.K.Tiwari - Issue is resolved, documents are OK and receiving the expected status back from ZATCA
@yamanhusari @dev.cksatc @Abhishek @anusv @hani @itsmeali7978 @paganapathy @sameer @saqeralmuntser @EslamSamiH @AhmedGalal @ismailme33 @githin @prakash.sathyamurthy @muneera_salah can someone please try now and confirm?
Same issue until now
Technical Proposal: Asynchronous API Integration for Fatoora Platform
- Executive Summary
Currently, the ZATCA Fatoora Platform primarily utilizes a Synchronous Request-Response model for reporting simplified tax invoices. While effective for standard volumes, this model creates significant overhead on both the taxpayerâs infrastructure and ZATCAâs gateway during peak loads. We propose the introduction of an Asynchronous Reporting Mechanism (Webhook-based) to improve system resilience, scalability, and the overall user experience at the Point of Sale (POS).
- Current Challenges (Pain Points)
- Latency Issues: Synchronous calls force the POS system to wait for a network response before finalizing the transaction, leading to delays in fast-paced retail environments.
- Resource Contention: High-frequency reporting during peak hours puts immense pressure on API Gateway resources, increasing the risk of timeouts and 504 Gateway errors.
- Tight Coupling: The current model requires both systems to be perfectly synchronized at the same millisecond to complete a handshake, which increases the risk of failure during minor network fluctuations.
- Proposed Solution: Asynchronous Webhook Pattern
We suggest implementing an Event-Driven approach characterized by the following workflow:
A. Immediate Acknowledgment
The taxpayer sends the invoice to a dedicated Async Endpoint. ZATCA responds immediately with an HTTP 202 (Accepted) status and a unique Correlation-ID or Job-ID.
B. Background Processing
ZATCA processes the invoice (validation, hashing, and status update) in an internal background queue at an optimized pace, decoupling the receipt of data from the validation logic.
C. Webhook Notification (Callback)
Once processing is complete, ZATCA pushes the final result (Success/Rejected) to a pre-registered Webhook URL hosted by the taxpayer.
- Technical & Business Benefits
| Benefit | Description |
|---|---|
| High Scalability | Allows the platform to âlevel outâ traffic spikes by queuing requests instead of handling them all in real-time. |
| Enhanced POS Performance | Merchants can continue serving customers without being blocked by network latency, as reporting happens in the background. |
| Reduced Overhead | Minimizes the duration of open TCP connections, freeing up server memory and CPU cycles on both ends. |
| Fault Tolerance | Webhooks can implement Retry Policies (e.g., Exponential Backoff) if the taxpayerâs listener is temporarily down. |
- Proposed Workflow Diagram
- Taxpayer â POST â ZATCA
- ZATCA â 202 Accepted { âuuidâ: â12345â } â Taxpayer
- ZATCA (Internal Queue ProcessingâŚ)
- ZATCA â POST /taxpayer/callback { âstatusâ: âAccepted/Rejected/Accepted with warningsâ, âuuidâ: â12345â } â Taxpayer
- Conclusion
Transitioning to an Asynchronous API Architecture aligns with global best practices for high-scale governmental platforms. It provides a more robust, âfuture-proofâ integration layer that can easily accommodate the growing volume of electronic invoices.
The issue persists. Reporting simplified invoices to ZATCA continues to take an excessively long time. When submitting a batch of invoices, some are successfully reported while others fail to report
Zatca response time was optimized around 05.00pm ksa time, until 10.00pm today, 05th Jan, but it again start repeating itâs abnormal behavior, same it behaves on 04th Jan, 03.30pm onwardsâŚ
As of Iâm writing, still zatca response time is very weakâŚ
Dear @Ankit.K.Tiwari , The issue persists. Due to these timeouts, we have a large volume of invoices to sync and will be unable to complete them within the 24-hour window. Please advise on how we should proceed.
Dear @Ankit.K.Tiwari Issue appeared to be temporarily resolved earlier yeasterday night; however, we are currently observing a recurrence of the same behavior, with timeouts occurring again.
Dear @Ankit.K.Tiwari
Issue is not resolved still, we are getting timeouts and large volume of invoices exceeded the time limit are pending to be reported.
Hi @Ankit.K.Tiwari Still issue Persist. Please take a look. Thanks in advance!
We have started receiving the following error at regular intervals after last nightâs fix, and the issue is still occurring:
{
âstatusCodeâ: 500,
âdataâ: âZATCA API Timed outâ
}â
issue still , yesterday at night it worked but today we got same issue
@yamanhusari @dev.cksatc @Abhishek @anusv @hani @itsmeali7978 @paganapathy @sameer @saqeralmuntser @EslamSamiH @AhmedGalal @ismailme33 @githin @prakash.sathyamurthy @muneera_salah @fareedulsahla @mohdzeeshan5c0 @Zaki1111
Dear All, your feedback is communicated with the team investigating the matter and further escalated to senior leadership as well. Apologies for the inconvenience, will keep you all posted here.
Dear @Ankit.K.Tiwari ,
We are facing the same issue. We have observed that a customer using a dedicated push server with a lower document volume is experiencing timeouts, whereas another customer with a dedicated server pushing a higher volume of documents is able to process them successfully, with the documents being cleared and reported without any issues.
We request your help in this matter.
Dear @Ankit.K.Tiwari,
We are also facing the same issue for several of our clients for B2C transactions dated 03/01/2026 and 04/01/2026 and 05/01/2026 related to B2C records.
Recently, we have also observed that the number of 409 error codes is increasing day by day. On further checking, we noticed that initially we receive error codes such as 500, 502, and 503, but after some time, when we re-push the same documents, we then receive error code 409.
Could you please check and let us know why we are first receiving 500-series HTTP errors and later getting a 409 (duplicate invoice) error? We would like to understand the underlying reason and expected behavior for these responses.
the problem become worse, now itâs not getting any response
The issue is still ongoing and getting worse
we have the same issue of latency when reporting and clearence c, can we have update when this issue will fix