Clientes

No hay /v1/customers. Un cliente se crea en la factura misma, mandando el objeto customer en vez de un customer_id: una integración que nunca abre el panel tiene que poder traer su propio receptor sin darlo de alta primero.

El id que devuelve la factura en customer.id es el del registro que quedó guardado. De ahí en adelante puedes mandar customer_id y ahorrarte los cuatro campos.

El objeto customer

tax_id: requerido; El RFC. Lo normalizamos y verificamos su dígito antes de mandarlo al SAT.
legal_name: requerido; La razón social tal como el SAT la tiene, sin el régimen de capital: "ACME" y no "ACME, S.A. de C.V.".
tax_regime: requerido; Su régimen, del catálogo c_RegimenFiscal. Tiene que ser el que el SAT le tiene registrado.
postal_code: requerido; El código postal de su domicilio fiscal, que el SAT compara contra su padrón.
default_cfdi_use: opcional; El uso que suele darle. G03 si no lo dices, y lo validamos contra su régimen: mándalo cuando el régimen no admite G03, como 605 o 616. Se puede cambiar factura por factura con cfdi_use.
email: opcional; A dónde mandarle el comprobante.
tax_residency / foreign_tax_id: opcional; Para un receptor extranjero.

Lo que mandas actualiza al cliente

Buscamos el RFC entre los clientes del emisor que timbra, no en toda tu cuenta. Si ya existe, el comprobante sale con la razón social, el régimen, el código postal y el uso que mandes. Cuando se timbra, guardamos esos datos en el cliente. Si el SAT lo rechaza, el cliente se queda como estaba. Un campo que no mandas no cambia, y el correo tampoco.

Si tu cuenta tiene varios emisores, cada uno tiene su propio registro del cliente. Lo que manda un emisor no cambia el registro de otro.

Con XAXX010101000, el público en general, ponemos el código postal del emisor. El SAT exige que sea el mismo que el del lugar de expedición.

Para corregir los datos de un cliente sin facturar, el panel: Clientes → el cliente → Editar.

El régimen decide el uso del CFDI

No todos los usos valen para todos los receptores: un régimen 605 no admite G03. Lo validamos antes de llamar al PAC contra la matriz del catálogo c_UsoCFDI. Esa combinación contesta validation_failed con el campo en details, sin borrador, sin folio y sin costar timbre.

Pasa en dos lugares. El cfdi_use de la factura se revisa contra el receptor, y details trae cfdi_use. El default_cfdi_use del cliente también: un receptor nuevo con régimen 605 y sin default_cfdi_use se rechaza aunque la factura mande otro uso, porque el cliente nace con G03. Ahí details trae default_cfdi_use.