If your e-invoicing platform connects directly to government tax authority APIs — ZATCA, UAE FTA, Turkey's GIB, or any EU CTC system — you're building on infrastructure you don't control. And that infrastructure fails. Often. The question isn't whether a government API will go down. It's what happens to your invoices when it does.
Most compliance platforms treat government downtime as an uncontrollable externality — invoices fail, users get error messages, and someone has to manually resubmit when the API comes back. InvoStaq takes a fundamentally different approach. We've built a five-layer resilience architecture that absorbs government API failures completely. Last quarter, government APIs were collectively down for 47 hours. InvoStaq users experienced zero hours of impact. Every single invoice was delivered.
47h
Govt API downtime last quarter
0h
InvoStaq user impact
5
Resilience layers
100%
Invoice delivery rate
The Downtime Reality
Government tax authority APIs are not built to the same reliability standards as commercial cloud services. They run on government-managed infrastructure with limited budgets, fewer engineers, and maintenance windows that often extend well beyond their scheduled time. Here's what we've observed across the APIs we integrate with:
| Tax Authority API | Downtime (Q4 '25) | Incidents | Avg Duration |
|---|---|---|---|
| ZATCA Fatoorah | 18.5h | 12 | 1.5h |
| Turkey GIB | 11.2h | 8 | 1.4h |
| UAE FTA | 6.8h | 5 | 1.4h |
| EU ViDA (Pilot) | 7.3h | 6 | 1.2h |
| Peppol SMP/SML | 3.2h | 3 | 1.1h |
| Total Combined | 47h | 34 | 1.4h |
That's 34 separate incidents across five major tax authority APIs in a single quarter. For companies that connect directly to these APIs without a resilience layer, each incident means failed invoices, manual resubmissions, compliance gaps, and frustrated finance teams. For InvoStaq users? Nothing. Business as usual.
The Real Cost of Unhandled Downtime
When a government API goes down and your platform doesn't handle it, invoices pile up unsent. Tax authorities have strict submission deadlines — ZATCA requires invoices within 24 hours of issuance. Missing that window means penalties, audit flags, and potential compliance violations. A single 3-hour outage during month-end close can delay thousands of invoices past their deadline.
Circuit Breaker Pattern
The first layer of InvoStaq's resilience architecture is the circuit breaker — borrowed from electrical engineering and adapted for distributed systems. Its job is simple: prevent cascading failures. When a government API starts failing, the circuit breaker detects the pattern and stops sending requests to it, protecting both your system and the failing API from overload.
All requests flow through normally. The circuit breaker monitors response codes and latency. As long as the failure rate stays below 5% and p95 latency stays under 2 seconds, the circuit remains closed. Invoices are submitted to the government API in real-time.
When the failure threshold is breached — typically 5 consecutive failures or a >15% error rate over 30 seconds — the circuit trips open. All subsequent requests are immediately routed to the smart queue instead of the failing API. No more wasted requests, no more timeout waiting. The circuit stays open for a configurable cooldown period (default: 60 seconds).
After the cooldown period, the circuit enters a half-open state. A single probe request is sent to the government API. If it succeeds, the circuit closes and normal traffic resumes. If it fails, the circuit reopens for another cooldown cycle. This prevents the thundering herd problem — thousands of queued requests don't slam the API the moment it shows signs of life.
The circuit breaker operates independently for each government API. If ZATCA goes down, only the ZATCA circuit opens — Peppol, UAE FTA, and all other endpoints continue operating normally. This granular isolation ensures that a single government outage never impacts invoices destined for other jurisdictions.
Smart Queuing
When the circuit breaker trips open, invoices don't disappear into a void. They're placed into InvoStaq's Smart Queue powered by Azure Service Bus — a fully managed, enterprise-grade message broker with guaranteed at-least-once delivery. No invoice is ever lost.
Every invoice placed in the queue is persisted to Azure Service Bus with transactional consistency. Even if InvoStaq's own infrastructure were to restart, queued invoices survive — they're stored in geo-redundant Azure storage with a 99.9995% durability SLA. Once an invoice enters the queue, delivery is guaranteed.
Not all invoices are equal. Invoices approaching their tax authority deadline (e.g., ZATCA's 24-hour window) are automatically prioritized in the queue. When the government API recovers, deadline-critical invoices are submitted first, ensuring compliance even when APIs have been down for hours.
If an invoice fails all retry attempts — even after the API recovers — it's moved to a Dead Letter Queue for manual review. This is an extremely rare event (less than 0.001% of all invoices), but when it happens, the DLQ provides full context: original invoice, all retry attempts, error codes, and timestamps. Your team has everything they need to resolve the issue without debugging from scratch.
InvoStaq's status dashboard shows real-time queue depth for every government API. When an API goes down, you can see invoices accumulating in the queue — and watch them drain automatically when the API recovers. Full transparency, zero manual intervention required.
From Your ERP's Perspective
When a government API is down, your ERP doesn't know — and doesn't need to. InvoStaq's API still accepts invoices with the same 200ms response time. The invoice is validated, signed, and queued for delivery. Your finance team sees a "Pending Delivery" status instead of "Submitted" — but their workflow is completely uninterrupted. When the API recovers, the status updates automatically.
Retry & Backoff
Naive retry logic — hitting the same failing endpoint every second — makes things worse. It overloads the recovering API, extends the outage, and wastes compute resources. InvoStaq uses exponential backoff with jitter — a battle-tested pattern used by AWS, Azure, and Google Cloud for their own internal services.
Each retry attempt waits longer than the previous one: 1 second, 2 seconds, 4 seconds, 8 seconds, 16 seconds. This gives the failing API time to recover without being hammered by constant requests. After 5 failed attempts, the invoice remains in the queue and is retried on the next circuit breaker half-open probe.
Pure exponential backoff has a flaw: if 1,000 invoices all start retrying at the same time, they'll all retry at 1s, then all at 2s, then all at 4s — creating synchronized load spikes. Jitter adds a random offset (±30%) to each delay, spreading retries across the time window and preventing the thundering herd effect.
Each government API has a configurable retry budget. ZATCA, with its strict 24-hour deadline, gets a more aggressive retry cadence (shorter backoff, more attempts). Peppol, with its store-and-forward architecture, can tolerate longer delays. Retry budgets are tuned based on each API's historical availability patterns and deadline requirements.
Every invoice submission includes an idempotency key — a unique identifier that guarantees the invoice is processed exactly once, even if a retry succeeds after a timeout. If InvoStaq's retry hits a government API that already received the invoice (the previous attempt succeeded but the response was lost), the duplicate is safely rejected. No double-submissions, ever.
// InvoStaq Retry Engine — Simplified
async function submitWithResilience(invoice, targetAPI) {
const maxRetries = 5;
const baseDelay = 1000; // 1 second
for (let attempt = 1; attempt <= maxRetries; attempt++) {
try {
const response = await targetAPI.submit(invoice, {
idempotencyKey: invoice.id,
timeout: 5000
});
return { status: "delivered", attempt };
} catch (error) {
if (attempt === maxRetries) {
await queue.moveToDLQ(invoice, error);
return { status: "dlq", attempts: maxRetries };
}
const jitter = Math.random() * 0.6 + 0.7; // ±30%
const delay = baseDelay * Math.pow(2, attempt - 1) * jitter;
await sleep(delay);
}
}
}Multi-Path Routing
The most powerful layer of InvoStaq's resilience architecture is multi-path routing — the ability to deliver invoices through alternative channels when the primary path is unavailable. This is especially critical for the Peppol network, where InvoStaq maintains connections to multiple certified Access Points with automatic failover.
Peppol Multi-AP Failover
InvoStaq is connected to 3 certified Peppol Access Points across different providers and data centers. If the primary AP goes down, invoices are automatically routed through the secondary AP — often before the primary AP's status page even reflects the outage. Failover is transparent, sub-second, and requires zero configuration from users.
Direct API Fallback
For tax authorities that support multiple submission channels (e.g., ZATCA's API vs. batch upload, or UAE FTA's real-time vs. scheduled submission), InvoStaq can automatically fall back to the alternative channel. If the real-time API is down, invoices are submitted via the batch endpoint — still within compliance deadlines.
Geographic Routing
Some government APIs have regional endpoints that fail independently. InvoStaq maintains a map of all available endpoints for each tax authority and routes around failures at the geographic level. If the EU-West Peppol SMP lookup fails, InvoStaq queries the EU-North SMP — same data, different infrastructure.
Protocol Negotiation
When a tax authority supports multiple protocols — AS4, AS2, REST, SFTP — InvoStaq can switch protocols if the primary one is experiencing issues. If ZATCA's REST API is failing but their AS4 endpoint is responsive, InvoStaq automatically negotiates the alternative protocol and delivers the invoice.
Multi-path routing is what transforms InvoStaq from a compliance platform into a compliance delivery network. Like a CDN routes web traffic around failed nodes, InvoStaq routes invoices around failed government APIs — automatically, transparently, and without any action from your team.
Status Transparency
Resilience without visibility is a black box. InvoStaq's public status page provides real-time monitoring of every government API we connect to — so you always know what's happening, even when the answer is "everything is fine because we're handling it."
Every government API we connect to is monitored with synthetic health checks every 30 seconds. The dashboard shows current status (up/degraded/down), response latency percentiles, error rates, and historical uptime. You can see exactly which APIs are healthy and which are experiencing issues — and how InvoStaq is handling each situation.
When an API is down, the status page shows real-time queue depth — how many invoices are waiting for delivery. You can watch invoices accumulate during an outage and drain instantly when the API recovers. This gives finance teams confidence that their invoices aren't lost — they're just waiting for the government's infrastructure to catch up.
For every government API incident, InvoStaq publishes a timeline: when the issue was detected, when the circuit breaker tripped, how many invoices were queued, when the API recovered, and how long the queue drain took. For major incidents, we publish a root cause analysis (RCA) if the tax authority provides one.
Real-World Scenario
Here's exactly what happened during a real ZATCA API outage on February 14, 2026 — and how InvoStaq's resilience architecture handled it:
ZATCA API starts returning 503 errors. InvoStaq's health check detects elevated error rate (23% failures over 30s window).
Circuit breaker trips to OPEN state. All ZATCA-bound invoices are routed to the smart queue. InvoStaq API continues accepting invoices normally — zero impact on ERP integrations.
3 hours 17 minutes of ZATCA downtime. During this period, 2,847 invoices are queued with guaranteed delivery. Half-open probes test ZATCA every 60 seconds — all fail.
Half-open probe returns HTTP 200. Circuit breaker transitions to CLOSED. Smart queue begins draining — priority-sorted by submission deadline.
All 2,847 queued invoices successfully delivered to ZATCA. Zero invoices missed their 24-hour deadline. Zero manual intervention required. Total user impact: 0 hours.
3h 17m
Outage Duration
ZATCA API was completely unreachable
2,847
Invoices Queued
All persisted with guaranteed delivery
0 min
User Impact
ERP integrations never interrupted
Build on Resilient Infrastructure
Government APIs will go down. Your invoicing shouldn't. InvoStaq's five-layer resilience architecture absorbs every outage — so your finance team never notices.