Clients and ANAF registry lookup (Romania)

1. POST /v1/clients creates or updates a client, deduplicated on tax_id and, failing that, on the normalized name.
2. GET /v1/clients lists clients with limit, offset and free-text q.
3. GET /v1/lookup/company/{tax_id} validates a Romanian CUI against the ANAF registry and returns the official data.
4. Pre-fill buyer from the lookup result so the e-Factura is not rejected over a stale name or address.

bash
# Deduplicated on tax_id, falling back to a normalized name:
# re-sending the same customer UPDATES it instead of creating a duplicate.
curl -sS -X POST https://api.4invoices.net/v1/clients \
  -H "Authorization: Bearer $ACCESS_TOKEN" \
  -H 'Content-Type: application/json' \
  -d '{
    "name": "Exemplu Comert SRL",
    "tax_id": "RO12345678",
    "email": "[email protected]",
    "country": "RO",
    "county": "Cluj",
    "city": "Cluj-Napoca",
    "address": "Str. Fabricii 12",
    "iban": "RO49AAAA1B31007593840000"
  }'

bash
curl -sS https://api.4invoices.net/v1/lookup/company/RO12345678 \
  -H "Authorization: Bearer $ACCESS_TOKEN"

# Official ANAF registry data — use it to pre-fill "buyer" so the
# e-Factura is not rejected for a stale name or address.

https://api.4invoices.net/v1 · https://api.4invoices.net/v1/openapi.json

• You do not need a stored client to issue: the buyer object can be sent inline on POST /invoices.
• For Romanian buyers, county must be the real county; for Bucharest put the sector in city.
• tax_id is accepted with or without the country prefix (RO12345678 or 12345678).
• Re-sending the same client updates the record, so a repeated import does not create duplicates.