SoftSDC

Integration guide

Connect your POS to SoftSDC. Learn the request flow, see client code in JavaScript, Python, C# and Java, and follow best practices for going live.

This guide shows how a POS works with SoftSDC. For every endpoint and field, see the API reference.

How the API runs

SoftSDC runs a small HTTP server on the device:

  • It serves JSON requests and responses.
  • It runs locally, at http://localhost:8431/api/v3 by default.
  • It keeps running in the background when the app is minimized.
  • It serves one POS. The POS can be on the same device or on another device on the network.

SoftSDC follows the communication protocol in the Technical Instructions for E-SDC developers. You cannot change the protocol parameters.

To learn how SoftSDC signs, stores and reports each invoice, read how it works.

Request flow

Verify the PIN

POST /pin with the smart card PIN. SoftSDC returns 0100 when it is correct.

Check that SoftSDC is ready

GET /status. Check isPinRequired, auditRequired, the status codes in gsc, and the tax labels in currentTaxRates.

Send the invoice

POST /invoices with the receipt data. SoftSDC signs it and returns the signature, the verification URL and the receipt text.

Print the journal text and a QR code made from verificationUrl, or use verificationQRCode. Customers use it to verify the receipt.

Sample clients

class SoftSDCClient {
  constructor(baseUrl = 'http://localhost:8431/api/v3') {
    this.baseUrl = baseUrl;
  }

  async verifyPin(pin) {
    const response = await fetch(`${this.baseUrl}/pin`, {
      method: 'POST',
      headers: { 'Content-Type': 'text/plain' },
      body: pin
    });
    return await response.text();
  }

  async createInvoice(invoice) {
    const response = await fetch(`${this.baseUrl}/invoices`, {
      method: 'POST',
      headers: {
        'Content-Type': 'application/json',
        'Accept': 'application/json'
      },
      body: JSON.stringify(invoice)
    });
    return await response.json();
  }
}

Best practices

Requests

  • Verify the PIN first, before you send invoices.
  • Send a RequestId with every request, for tracking and recovery.
  • Use timeouts. Signing can take time. A 30-second timeout is a good start.
  • Retry network failures with exponential backoff.
  • Store responses. Keep the fiscalization responses for your audit trail.

Errors

  • Check the status before sending. Make sure SoftSDC is ready.
  • Handle every status code. See error codes for the list and sample handlers.
  • Log every API call.

Performance

  • Reuse connections with HTTP keep-alive.
  • Fiscalize each invoice on its own. You can batch work in your POS, but SoftSDC signs one invoice per request.
  • Cache status responses for 30 to 60 seconds.
  • Watch the status for warnings before they become errors, and track response times.
  • Do not flood the service. Respect its limits and use circuit breakers.

Testing

Training invoices

Use the Training invoice type to test without fiscal effect. Training invoices are clearly marked and do not count in fiscal reporting.

{
  "invoiceType": "Training"
}

Send the rest of the invoice fields as usual.

Test endpoints

  • GET /api/v3/attention checks that the service is running.
  • POST /api/v3/test-invoice creates a test invoice, if enabled.

Before you go live

Run Create test invoice in the app to check the setup.
Test in both online and offline mode.
Check that QR codes are created and verify correctly.
Test error handling and recovery.
Validate against the Tax Authority test environment.

Need help?

On this page