Modelo de estados
O conceito central da integração.
Aqui está a inversão em relação a uma API REST convencional. A aplicação não pergunta se a chamada foi atendida. Ela declara: quando o estado for X, mostre isto. O SDK empurra o estado; a tela é uma consequência.
Os comandos — ficar disponível, entrar em pausa, discar, desligar — são intenções sem retorno. Não devolvem sucesso nem erro. Quem confirma é a próxima transição de estado. Um comando inválido no estado atual é descartado silenciosamente.
Nove estados; a interface inteira é uma função de qual deles está ativo. Arestas menores ficaram de fora do diagrama para manter a leitura: callRinging volta para idle se a chamada cair antes de ser atendida, goOffline() vale a partir de quase todo estado, e as falhas aparecem como startupError (na inicialização) ou manualCallFailed (chamada manual que não completa).
Os estados
Onde a máquina de estados executa
A máquina roda no browser — o SDK embarca o xstate como dependência. Em execução medida, a transição entre o comando e a mudança de estado leva cerca de 5 ms, rápido demais para uma ida e volta de rede. O estado local é otimista e a sincronização com o backend acontece por fora.
Na prática isso favorece a responsividade da interface, mas significa que estado na tela não é prova de estado no servidor: para auditoria de disponibilidade de agente, a fonte de verdade é o relatório da plataforma.