> ## Documentation Index
> Fetch the complete documentation index at: https://docs.lerian.studio/llms.txt
> Use this file to discover all available pages before exploring further.

# Primeiros passos com o Flowker

> Veja como o Flowker automatiza operações financeiras com cenários reais de negócio, da orquestração de pagamentos à prevenção de fraude.

As operações financeiras envolvem várias etapas, aprovações e verificações externas. Gerenciar isso à mão leva a erros, atrasos e lacunas de compliance. O Flowker deixa você definir esses processos uma vez como workflows e executá-los de forma consistente, com registros de execução por etapa e visibilidade em tempo real.

## Como o Flowker funciona

***

Você começa explorando quais integrações estão disponíveis, conecta-as ao seu ambiente, define um workflow que modela o seu processo de negócio e então o executa. Cada execução deixa um registro rastreável e disponível para inspeção pela API.

**1. Explore o catálogo**

Navegue pelo catálogo para descobrir os provedores, os executores e os gatilhos disponíveis no seu deploy do Flowker.

**2. Conecte os seus provedores**

Crie uma configuração de provedor para cada serviço externo que os seus workflows chamam: motores antifraude, processadores de pagamento, provedores de KYC e serviços de notificação. Ela identifica a conexão que um nó de workflow usa para aquele serviço.

**3. Defina os seus workflows**

Modele o seu processo de negócio como um workflow: defina as etapas (nós), a ordem em que elas rodam (arestas) e as condições que controlam a ramificação.

**4. Execute e monitore**

Dispare workflows pela API, por um webhook ou por um gatilho de agendamento. Leia o status de cada execução e recupere os resultados quando ela terminar.

## O que você pode automatizar

***

O Flowker foi feito para processos financeiros de várias etapas que exigem confiabilidade, rastreabilidade e integração com serviços externos.

### Orquestração de pagamentos

**O desafio:** um pagamento envolve várias etapas: validação, roteamento para o provedor certo, confirmação e notificação. Quando isso é feito à mão ou por integrações espalhadas, as falhas passam despercebidas e a conciliação fica dolorosa.

**Como o Flowker resolve:** defina um workflow que coordena todo o ciclo de vida do pagamento:

1. **Gatilho**: uma nova requisição de pagamento chega pela API ou por webhook.
2. **Validar**: verifique se os dados do pagamento estão completos e se a conta tem saldo suficiente.
3. **Rotear**: escolha o provedor de pagamento adequado com base no valor, na moeda ou no trilho (Pix, TED, SWIFT).
4. **Confirmar**: chame o provedor e espere a confirmação.
5. **Notificar**: envie um evento de confirmação ao cliente e atualize o ledger.

Para as chamadas de executor, você configura o comportamento de nova tentativa por nó. Por padrão, as chamadas `POST` e `PATCH` rodam uma vez, a menos que você ative as novas tentativas no nó. O Flowker não deduplica o efeito colateral no provedor durante as novas tentativas: a `Idempotency-Key` da execução deduplica execuções do Flowker, não as requisições de saída ao provedor.

Ative as novas tentativas em um nó `POST` ou `PATCH` apenas quando a operação do provedor for idempotente. Você também pode ativar quando o provedor documenta uma chave de negócio estável e a aplica de forma atômica. Envie essa chave em um header como chave de idempotência em cada tentativa. Caso contrário, mantenha as novas tentativas desabilitadas no nó. O Flowker registra cada nó de executor, condicional e ação executado para conciliação e revisão.

### Validação antifraude

**O desafio:** as verificações de fraude devem acontecer antes do processamento da transação. Elas envolvem serviços externos, lógica de pontuação e limiares diferentes conforme o tipo de transação. Deixar essa lógica fixa no código a torna difícil de manter.

**Como o Flowker resolve:** defina um workflow pré-transação que roda as verificações de fraude antes de qualquer coisa chegar ao ledger:

1. **Gatilho**: uma nova transação chega.
2. **Enriquecer**: colete o histórico do cliente, os dados do dispositivo e a geolocalização dos sistemas internos.
3. **Pontuar**: chame um ou mais provedores de detecção de fraude e colete as pontuações de risco.
4. **Decidir**: aplique as regras: se a pontuação estiver acima do limiar, bloqueie. Se estiver no limite, marque para revisão. Se estiver limpa, aprove.
5. **Agir**: siga com a transação ou avise o time de compliance.

Todas as decisões são rastreáveis. Você pode ajustar os limiares e adicionar novos provedores sem mudar a lógica central.

### Onboarding de clientes

**O desafio:** o onboarding de um novo cliente exige verificação de identidade, validação de documentos, verificações de AML/KYC e criação de conta. Essas etapas envolvem vários provedores externos e exigências regulatórias que variam por jurisdição.

**Como o Flowker resolve:** defina um workflow de onboarding que automatiza todo o processo:

1. **Gatilho**: um novo cadastro de cliente chega.
2. **Verificar identidade**: chame um provedor de KYC para validar os documentos e a identidade do cliente.
3. **Checar compliance**: rode a triagem de AML contra listas de sanções e bases de PEP.
4. **Avaliar risco**: aplique as regras internas de risco com base no perfil do cliente, na jurisdição e no histórico de transações.
5. **Criar conta**: se todas as verificações passarem, crie a conta do cliente no sistema.
6. **Notificar**: envie um e-mail de boas-vindas ou avise o gerente de relacionamento se for preciso uma revisão manual.

O resultado de cada etapa determina a próxima ação. Se uma verificação falha, o workflow para e registra o resultado de etapa que explica o motivo.

### Workflows de aprovação manual

**O desafio:** algumas operações (transferências de alto valor, mudanças de limite de crédito, encerramentos de conta) exigem aprovação humana. Mas montar fluxos de aprovação com notificações por e-mail, timeouts e caminhos de escalonamento é complexo e sujeito a erros.

**Como o Flowker resolve:** defina um workflow que chama um serviço externo de aprovação por um nó de executor:

1. **Gatilho**: uma requisição de transferência de alto valor chega.
2. **Avaliar**: verifique o valor, o perfil de risco do cliente e as políticas internas.
3. **Pedir aprovação**: chame um serviço externo de aprovação (gestor, responsável por compliance) por um nó de executor.
4. **Decidir**: um nó condicional avalia a resposta da aprovação.
5. **Agir**: se aprovada, siga com a transferência. Se recusada, cancele e avise quem pediu.

Você pode definir aprovações em vários níveis encadeando nós de executor que chamam o seu serviço de aprovação em cada nível.

## Principais recursos

***

* **Validação pré-ledger**: coloque cada verificação antes do nó de lançamento no seu grafo e use nós condicionais com arestas de `sourceHandle` correspondente para rotear até o lançamento apenas os resultados aprovados.
* **Registros de execução por etapa**: os resultados da execução registram status, duração, saída e erro de cada nó de executor, condicional ou ação executado. Os nós de gatilho começam o percurso do grafo e não criam registros de etapa de execução.
* **Integrações com provedores**: conecte a motores antifraude, provedores de KYC, processadores de pagamento e qualquer serviço baseado em HTTP.
* **Ramificação condicional**: um nó condicional segue as arestas cujo `sourceHandle` corresponde ao resultado dele, então você pode rotear a execução com base em resultados de etapas, valores, scores de risco ou qualquer campo de dados.
* **Execução idempotente**: reutilizar uma `Idempotency-Key` no mesmo workflow devolve a execução existente do Flowker em vez de criar outra, enquanto essa execução existir. Uma chave já usada em outro workflow responde `FLK-0511`. A execução direta exige uma chave não vazia. O header do webhook é opcional.
* **Esperas temporizadas**: um nó wait pausa uma execução por um tempo definido, de até 12 horas, e a execução mostra o status `waiting` nesse intervalo.
* **Monitoramento de execuções**: leia o status da execução pela API enquanto um workflow roda. Recupere os resultados da execução, com os resultados das etapas, depois que ela chega a um estado terminal.

> [!NOTE]
>
> Com `PLUGIN_AUTH_ENABLED=true`, as rotas de gerenciamento do Flowker exigem um token Bearer e aplicam permissões por recurso e ação. Essa configuração é obrigatória em produção. O ingresso assinado do Streaming Hub em `/v1/hub/webhooks/` usa a assinatura do hub em vez de um token Bearer. As credenciais específicas de cada provedor (para serviços externos) são gerenciadas por [configurações de provedor](https://docs.lerian.studio/pt/reference/products/flowker/list-provider-configurations.md).

## Próximos passos

***

> [card] [Conceitos centrais](https://docs.lerian.studio/pt/products/flowker/flowker-concepts.md)
>
> Entenda em detalhe os workflows, os nós, as arestas e o modelo de execução.

> [card] [O que é o Flowker?](https://docs.lerian.studio/pt/products/flowker/what-is-flowker.md)
>
> Leia sobre a arquitetura, os recursos e a filosofia de design do Flowker.

> [card] [Referência da API](https://docs.lerian.studio/pt/reference/products/flowker/create-workflow.md)
>
> Explore a API completa de workflows, execuções e configurações.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.