# Alguns motivadores para termos APIs de integração dedicadas

- **Quebras de versão de serviço de negócios recorrentes**
Todos os clientes que estavam usando as APIs de negócio eram obrigados a mudar a versão de forma sincronizada com evolução do CRM, mesmo que o contrato em si não tenha sido alterado. O que acontecia era que todas as integrações de clientes paravam no instante que o CRM era atualizado.

- **Contrato das APIs de integração podem ser diferentes das APIs de negócio**
Nem todos os campos de negócio precisam ser integrados, pode ser exposto apenas o que faz sentido integrar.

- **Regras de negócios que não fazem sentido para a integração**
Existem regras de negócios que não fazem sentido para a integração. Como exemplo, pela API de negócio não consigo inserir um item em venda que esteja inativo. Para cargas de históricos de venda deve ser possível.
** Fator legado

- **Regras de integração que não fazem sentido para negócio**
Exemplo - Na inserção de dado via integração é obrigatório o preenchimento do campo externalId. Via API de negócio este campo não existe, não fazendo sentido obrigar.

- **Exposição controlada de APIs de integração**
Podemos liberar o acesso externo às APIs somente via integration-router e bloquear acessos diretos a APIs por questões de segurança. Pode ser citado também que em algumas ocorrências de DDOS (mesmo sem a intenção por parte do conector) foi desativado o serviço Integration-router para cessar as tentativas de acesso.

- **Possibilidade de evoluções de recursos para integração**
Exemplos:
Abstração de recurso de patch (atualização parcial)
Expor a resposta completa de uma operação em uma inserção ou atualização
Pacotes de quantidade de requisição para integração
Permitir usar externalId como chave do registro(ao invés de somente o ID)
Criar containers dedicados a integração para não afetar os containers de negócio