Pular para o conteúdo

Sincronizar clientes com CRM ou ERP

O cliente existe no seu CRM ou ERP e no Faturei Hoje. Este guia mostra como levar o cadastro de um lado para o outro sem criar cliente repetido.

São dois sentidos, e cada um tem a sua ferramenta:

SentidoComo
Do seu sistema para o FatureiProcurar, depois criar ou editar. É o que esta página mostra
Do Faturei para o seu sistemaOs eventos client.created, client.updated e client.deleted avisam na hora, e a sincronização incremental garante que nada ficou para trás
PermissãoPara quê
clients:readProcurar o cliente antes de gravar
clients:createCadastrar quem não existe
clients:updateAtualizar quem já existe

O jeito mais seguro de ligar os dois cadastros é o id. Na primeira vez que você achar ou criar o cliente, guarde o id do Faturei Hoje no registro do seu sistema. Daí em diante, edite direto por ele, com PATCH /public/v1/clients/{id}, sem procurar de novo.

Procurar por e-mail, telefone ou documento serve para a primeira ligação, quando você ainda não tem o id.

POST /public/v1/clients não confere se o cliente já existe: duas chamadas com o mesmo e-mail criam dois cadastros. Então procure primeiro. GET /public/v1/clients aceita três filtros de cadastro exato:

FiltroComo compara
emailE-mail igual, sem diferenciar maiúscula de minúscula
phoneO mesmo telefone, com ou sem o nono dígito. Telefone inválido responde 422
cpf_cnpjOs mesmos dígitos, com ou sem pontuação

Há também search, a mesma busca da tela de clientes, por nome, e-mail, telefone ou documento. Ela é boa para gente procurando, não para decidir sozinha se o cliente é o mesmo.

A base pode ter cadastro repetido de antes da integração. Se a busca trouxer mais de um, não escolha no escuro: registre o caso e resolva com a empresa.

Terminal window
# 1. Procurar pelo e-mail
curl "https://api.fatureihoje.com/public/v1/clients?email=contato%40marcenariasouza.com.br&limit=2" \
-H "Authorization: Bearer $FH_API_KEY"
# 2a. Não achou: criar
# Gere a chave uma vez e guarde: numa nova tentativa, repita com o mesmo valor.
CREATE_KEY=$(uuidgen)
curl -X POST "https://api.fatureihoje.com/public/v1/clients" \
-H "Authorization: Bearer $FH_API_KEY" \
-H "Content-Type: application/json" \
-H "Idempotency-Key: $CREATE_KEY" \
-d '{
"name": "Marcenaria Souza",
"email": "contato@marcenariasouza.com.br",
"phone": "+5511988887777",
"cpf_cnpj": "12345678000190",
"person_type": "pj"
}'
# 2b. Achou: atualizar pelo id que veio na busca
CLIENT_ID="0d9a7c5e-3f1b-4d2a-8c6e-4a2b0c8e6f1d"
curl -X PATCH "https://api.fatureihoje.com/public/v1/clients/$CLIENT_ID" \
-H "Authorization: Bearer $FH_API_KEY" \
-H "Content-Type: application/json" \
-d '{ "phone": "+5511988887777" }'

O cadastro aceita os mesmos campos do formulário do painel, inclusive os fiscais (razão social, inscrições, endereço fiscal). A lista completa, com formato e tamanho de cada um, está na Referência.

RespostaO que fazer
422 validation_failedCorrija o campo apontado em errors (um telefone inválido no filtro, por exemplo)
404 resource_not_foundO cliente do PATCH não existe mais, ou não é da empresa
429 rate_limit_exceededEspere o Retry-After e repita. Veja Limites de uso
5xx ou falha de redeRepita; no POST, com a mesma Idempotency-Key

O PATCH altera só os campos que vierem na chamada. Campo que não vem fica exatamente como está, e null limpa um campo opcional.

Use isso a seu favor: mande só os campos que o seu sistema é dono. Se a equipe cuida das observações pelo painel e o seu ERP cuida do documento e do endereço fiscal, o ERP nunca manda notes, e ninguém apaga o trabalho do outro.

Quando os dois sentidos estão ligados, é fácil criar um laço: o seu sistema atualiza o cliente, o Faturei Hoje manda client.updated, o seu sistema grava de novo, e assim por diante.

  • Antes de gravar, compare. Se o valor que chegou é igual ao que você já tem, não grave nem chame a API.
  • Num client.updated, o changed_fields diz o que mudou. Se são só campos que o seu sistema acabou de mandar, com os mesmos valores, o evento é o eco da sua própria gravação.

Cliente com endereço já nasce com o endereço “Principal” na lista de endereços. Endereços a mais (obra, filial, casa de praia) ficam em GET /public/v1/clients/{client_id}/addresses e POST /public/v1/clients/{client_id}/addresses.

DELETE /public/v1/clients/{id} apaga o cadastro de vez, como no painel, com endereços, observações, vínculos de grupo, acesso ao portal, inventário e obras. Ordens de serviço, vendas, orçamentos, tarefas, lançamentos, contratos e notas fiscais continuam existindo, sem o cliente. Não tem volta.

Se no seu sistema “excluir” quer dizer “não é mais cliente”, talvez o que você quer seja status: "inactive" num PATCH. A decisão é sua; a API faz o que você pedir.