Legacy V2 API

The Legacy V2 API exists for compatibility with older POS integrations (the FiscoBridge-era contract). New integrations should use v3. V2 signing reuses the exact same fiscalisation pipeline as v3 — only the request parser and the returned result shape differ. 

 Endpoints 
 
 Endpoint Purpose 
 
 GET /api/attention Availability + readers. 
 GET /api/status Availability + readers. 
 POST /api/sign Sign an invoice (V2 request → V2 result). 
 POST /api/sign/SignInvoice Alias of /api/sign . 
 
 
 PIN verification uses the same POST /api/v3/pin as v3 — the cached PIN is shared across both APIs. 

 Key differences from v3 
 
 Single payment type. The V2 request carries one request-level paymentType (not a payment array). A single payment is synthesised with an amount equal to the sum of item totals. 
 Stringly-typed nested fields. items and options are provided as JSON strings , and item labels is a JSON string such as "[\"A\"]" . 
 buyerCostCenterId limit is 15 chars in V2 (50 in v3). 
 unitPrice defaults to 1 if omitted (v3 requires it). 
 Result shape is the abbreviated legacy FiscalizationResultV2 (short field names) rather than the full-named v3 InvoiceResult . The underlying values (verification URL, QR, journal, signature, counters) are the same. 
 

 Request fields (V2) 
 
 Field Notes 
 
 invoiceType Normal / ProForma / Copy / Training / Advance . 
 transactionType Sale / Refund . 
 paymentType Single value: Cash , Card , etc. 
 items JSON string of an array of { gtin, name, quantity, unitPrice, labels, totalAmount } ; labels itself is a JSON string like "[\"A\"]" . 
 dateAndTimeOfIssue , cashier , buyerId , buyerCostCenterId , invoiceNumber , referentDocumentNumber , options As v3, with the V2 limits noted above. 
 
 

 Validation 
 V2 validation returns the same 400 modelState shape as v3; a parse failure (unparseable date, wrong JSON type) is reported as 2805 (field value invalid). You can dry-run a V2 request with POST /api/v3/invoices/v2/validate . 

 Recommendation 
 Use V2 only to keep an existing POS working. For new development, target v3 for the typed payment array, the richer result fields, and RequestId idempotency.