An import row without an address is a bad row
A customer import row with an incomplete address is now reported as a bad row instead of being created with placeholder values.
A row whose address was incomplete used to be imported anyway, with the missing parts filled in — "Sin especificar", "00000", "N/A" — so you ended up with customers carrying an address nobody had declared. The row is now reported, in its own position, with its own errors, and no customer is created for it.
The rest of the file imports as before: a bad row is bounded to itself.
What else changed
- Fewer customers are created than before for the same file, and the difference is exactly the rows that were being filled in. The preview reports them the same way the real import does, so you can see the count before committing.
- What to do. Complete the address columns for the reported rows and re-import them, or accept them as rejected. There is nothing to migrate: existing customers are untouched.
Endpoints
- POST/v1/companies/{company_id}/customers/importsA row with an incomplete address is reported, not filled in
- POST/v1/companies/{company_id}/customers/importss/previewThe preview reports the same rows the import will reject
Where to go next
Clearer rejections, and updates that do not re-ask the census
A customer update only asks the AEAT census when the fiscal pair changes, the invitation `404` stops saying "pending", and readiness names an incomplete identity.
Payment connections are addressed by id
The `{provider}` path segment becomes `{connection_id}` on nine payment-connection paths. The old paths are gone, with no coexistence window.