Skip to content
FiskHub

upstream_unavailable

Carried inside a 200 invoice body as `fiscal_error`. NOT an HTTP error.
{
  "id": "inv_01J9Z4T7M2K8Q6R3V5X1Y0B2C4",
  "status": "retrying",
  "jir": null,
  "zki": "e4d909c290d0fb1ca068ffaddf22cbd0",
  "qr_payload": "https://porezna.gov.hr/rn?zki=e4d909c290d0fb1ca068ffaddf22cbd0&datv=20260827_1032&izn=450",
  "number": "1041",
  "occurred_at": "2026-08-27T10:32:11+02:00",
  "total": "4.50",
  "currency": "EUR",
  "fiscal_error": {
    "code": "upstream_unavailable",
    "message": "Tax Administration did not respond. Will retry automatically.",
    "retry_scheduled": true
  }
}

What happened

FiskHub could not reach the Croatian Tax Administration, or reached it and got no answer within the timeout. Two sequential attempts were made, with a 4-second socket timeout each, before giving up on the round trip.

Causes are ordinary: a scheduled maintenance window, an outage on their side, congestion, a network partition between us and them.

Should you retry?

No — FiskHub already is. retry_scheduled is true and the invoice is in retrying.

A sweep runs every five minutes, selects invoices in this state whose 30-day deadline has not passed, orders them by deadline ascending so the most endangered go first, and resends them with late delivery (NakDost) set and a fresh message id. The business data does not change, so the ZKI does not change. Nothing is required of you.

Resubmitting the sale yourself would be a second fiscalization attempt for one sale. The Idempotency-Key protects you from the worst of it, but the right action is to do nothing.

The fix

Nothing to fix on your side. What to do:

  1. Complete the sale. Print the receipt from zki and qr_payload, omit the JIR line, dispense.

  2. Record the invoice id if you want to confirm later.

  3. Check back when convenient — a one-off GET a few minutes later, or a daily reconciliation:

    Terminal window
    curl -sS "https://api.fiskhub.com/v1/invoices/inv_01J9Z4T7M2K8Q6R3V5X1Y0B2C4" \
      -H "Authorization: Bearer $FISKHUB_API_KEY"

    Most outages clear within one or two sweep passes and the invoice quietly becomes confirmed.

Do not poll in a tight loop — see rate limits. There are no webhooks; the synchronous design removed the need for them.

If it keeps happening

Probe the endpoint directly:

Terminal window
curl -sS https://api.fiskhub.com/v1/health/fiscal \
  -H "Authorization: Bearer $FISKHUB_API_KEY"

reachable: false means the problem is upstream and there is nothing to do but keep selling. Note that the TEST endpoint has scheduled windows — weekdays 16:00–17:00 and Sundays 08:00–12:00, Europe/Zagreb — so this is expected during those hours on fh_test_ keys.