Suspensão e inadimplência

Selo de estado: GA-candidato · Atualizado em 2026-09-06. Fonte de estado: matriz de estados do produto (verificação central de acesso, suspensão consistente, fail-closed). Limite atual do produto = Preview.

O que acontece quando a assinatura fica em atraso, e por quê. A regra vive em um lugar só (a verificação central de acesso) e é previsível: ações caras bloqueiam, leitura barata continua.

Conceitos#

• Ação cara: consome dinheiro/recursos. São cinco: atualização manual (refresh_manual), execução/envio de relatórios (report_run), consultas via API (api_query), exportação (export) e recursos de IA (ia).
• Leitura barata: ver um dashboard/snapshot já materializado — nunca bloqueia (serve dado pronto, sem custo de processamento para o dono).
• Dois sinais de cobrança: o status local (do provedor de pagamento) e a central udiApps (contrato do produto).

Como a verificação decide (ordem)#

1. Status local em past_due, suspended ou canceled ⇒ bloqueia ações caras (HTTP 402). Basta o sinal local; nem consulta a central.
2. Senão, central udiApps com allowed: false ⇒ bloqueia (suspenso → 402; sem contrato → 403).
3. Fail-open só quando não há sinal nenhum: status local não-negativo (active, inactive, pending) e central sem resposta. inactive/ pending não bloqueiam de propósito — é o default de workspace novo/trial.
4. Leitura barata nunca bloqueia (dashboard público/snapshot).
5. Navegação no app continua: o inadimplente precisa navegar até Planos para pagar — por isso a navegação não é derrubada; só as ações caras ficam bloqueadas em cada ponto de execução.

Disponibilidade#

• Planos: todos (a verificação é núcleo de segurança e cobrança).
• Estado: GA-candidato (fail-closed, coberto por testes); a prova entre clientes em nuvem ainda é pendente (claim #13).

Permissões#

• Regularizar o pagamento (acessar Planos, pagar) exige owner (billing.manage).
• O bloqueio de ação cara vale para todos os membros do workspace, independente do papel.

Mensagens que o usuário vê (pt-BR)#

Validação#

• Ações caras retornam 402/403 com mensagem pt-BR pronta; leitura de dashboard segue no ar.
• A tela de regularização (Planos) permanece acessível mesmo em atraso.
• Após pagar, o status volta a active e as ações caras são liberadas (a central tem cache de ~60 s).

Exemplo#

A Comércio Aurora entra em past_due. Maria e a equipe ainda veem os dashboards existentes (snapshot), mas não conseguem: rodar refresh manual, enviar relatórios, exportar, usar IA ou consultar via API — cada tentativa retorna 402 com o link para Planos. Maria (owner) acessa Planos, paga por Pix, e em segundos tudo volta a funcionar.

Custo#

• A verificação em si não consome recursos: R$ 0.
• O objetivo é justamente conter custo quando a conta não está em dia.

Segurança#

• Regra única e fail-closed: um id de workspace inválido nunca "passa por engano".
• API /api/v1 aplica rate limit fail-closed (por chave e por workspace) e o verificação de assinatura antes de tocar o datalake pago.
• Leitura barata isolada das ações caras evita "derrubar" quem só consome.

Limites#

• /api/v1 está fora de GA (claim #6) — não use como rota de produção GA.
• O fail-open é intencional e restrito ao caso "nenhum sinal negativo" (workspace novo/trial); não é um bypass.
• A reativação depende do provedor de pagamento confirmar o pagamento.

Troubleshooting#

Próximos passos: volte ao índice de Administração ou revise Planos e Consumo e quotas.

Estado & evidência: verificação central de acesso, fail-closed = GA-candidato; prova entre clientes em nuvem = pendente (claim #13). Estado derivado da matriz de estados do produto (verificação central de acesso).