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 apaymentarray). A single payment is synthesised with an amount equal to the sum of item totals. - Stringly-typed nested fields.
itemsandoptionsare provided as JSON strings, and itemlabelsis a JSON string such as"[\"A\"]". buyerCostCenterIdlimit is 15 chars in V2 (50 in v3).unitPricedefaults to 1 if omitted (v3 requires it).- Result shape is the abbreviated legacy
FiscalizationResultV2(short field names) rather than the full-named v3InvoiceResult. 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.