Skip to main content
O modelo de licenciamento SUOT foi projetado para equipes de desenvolvimento e software houses — não para desenvolvedores individuais. A organização é a titular da licença, múltiplos desenvolvedores compartilham o acesso e os tokens Composer são a ponte entre a licença comercial e o repositório privado de pacotes. Entender essas distinções evita surpresas em ambientes de CI/CD, onboarding de novos membros e renovações de plano.

​
A organização é titular da licença

A licença SUOT pertence à organização — a empresa ou entidade jurídica que contratou o serviço — não ao desenvolvedor individual que fez o cadastro. Isso significa:
  • Todos os desenvolvedores da organização podem gerar tokens de acesso ao repositório privado packages.suot.dev
  • A saída de um desenvolvedor da equipe não invalida a licença nem os tokens dos demais
  • A renovação e o gerenciamento do plano são responsabilidade da organização, não de cada membro individualmente
  • Novos membros da equipe herdam o acesso ao repositório simplesmente criando seus próprios tokens — nenhuma licença adicional é necessária
Se a sua organização tiver múltiplos CNPJs (ex.: holding com subsidiárias), cada entidade jurídica que utilizar os SDKs SUOT em produção deve ter sua própria licença. Entre em contato com developers.suot.dev para discutir arranjos de grupo.

​
Licença vs. assinatura

Esses dois termos têm significados distintos no contexto SUOT e é importante não confundi-los:
ConceitoO que éOnde é gerenciado
AssinaturaO relacionamento comercial: plano contratado, faturamento, ciclo de renovaçãoPortal da organização em developers.suot.dev
LicençaO acesso técnico: permissão para baixar pacotes de packages.suot.dev e usar versões específicas dos SDKsGerada automaticamente a partir da assinatura ativa
Uma assinatura ativa gera uma licença ativa. Quando a assinatura vence ou é cancelada, a licença para de conceder acesso a novas versões dos SDKs — mas o software já instalado continua funcionando normalmente (veja a seção Vencimento da licença abaixo). Para dúvidas sobre planos, upgrades e faturamento, acesse developers.suot.dev.

​
Tokens Composer

Os tokens são o mecanismo de autenticação que conecta o Composer ao repositório privado packages.suot.dev. Eles não são licenças — são credenciais de acesso geradas dentro do escopo de uma licença. Boas práticas para tokens:
  • Cada desenvolvedor deve ter seu próprio token — isso permite revogar o acesso individualmente sem afetar os demais
  • Cada pipeline de CI/CD (GitHub Actions, GitLab CI, Bitbucket Pipelines etc.) deve ter seu próprio token rotacionado regularmente
  • Nunca commite um token diretamente no repositório de código — use variáveis de ambiente ou secrets do seu serviço de CI/CD
  • Tokens comprometidos podem ser revogados a qualquer momento pelo administrador da organização no portal
# Configuração do token no auth.json do Composer (não versionar este arquivo)
composer config --global http-basic.packages.suot.dev seu-token-aqui x-token

// auth.json — adicione ao .gitignore
{
    "http-basic": {
        "packages.suot.dev": {
            "username": "seu-token-aqui",
            "password": "x-token"
        }
    }
}
O arquivo auth.json contém credenciais de acesso. Certifique-se de que ele está listado no .gitignore do projeto e nunca seja incluído em imagens Docker publicadas.
Para criar e gerenciar tokens da sua organização, consulte a documentação de Tokens Composer.

​
Vencimento da licença

O que acontece quando a licença da sua organização vence?
ImpactoDetalhes
❌ Acesso a novas versões dos SDKsNão é possível baixar versões lançadas após o vencimento
❌ Suporte técnico SUOTTickets e canais de suporte ficam indisponíveis
✅ Software já instaladoContinua funcionando normalmente em produção
✅ Versões já baixadasFicam disponíveis no Composer cache e no vendor/ do projeto
Não existe kill switch no runtime dos SDKs SUOT. O código instalado não verifica periodicamente se a licença está ativa. Uma aplicação em produção com os SDKs SUOT instalados continuará funcionando após o vencimento da licença — ela simplesmente não poderá atualizar para versões mais recentes até que a assinatura seja renovada.
Planeje as renovações com antecedência. Se a sua organização depende de atualizações dos SDKs para manutenção de segurança, correções de bugs ou novos recursos regulatórios (ex.: uma versão de leiaute da SEFAZ), o vencimento da licença pode bloquear um deploy crítico. Recomendamos renovar com pelo menos 30 dias de antecedência.

​
Software houses e SaaS

Se a sua organização desenvolve um produto (SaaS, ERP, TMS, etc.) que utiliza os SDKs SUOT internamente, o modelo é o seguinte:
  • A organização desenvolvedora do produto (sua empresa) é titular da licença SUOT
  • Os usuários finais do produto (seus clientes) não precisam de licença SUOT — eles usam o produto, não o SDK diretamente
  • A licença cobre o uso dos SDKs no código do produto, independentemente de quantos clientes finais o produto atende
Isso significa que você não precisa repassar custos de licenciamento SUOT para cada cliente do seu produto — a licença é da organização que desenvolve e mantém o software. 
Software house (titular da licença SUOT)
    └── Produto SaaS / ERP / TMS
            ├── Cliente A  ← usa o produto, não precisa de licença SUOT
            ├── Cliente B  ← usa o produto, não precisa de licença SUOT
            └── Cliente C  ← usa o produto, não precisa de licença SUOT
Se os seus clientes integrarem diretamente com os SDKs SUOT (ex.: você distribui os SDKs como parte de um kit de integração que eles instalam no ambiente deles), entre em contato com developers.suot.dev para avaliar o modelo de licenciamento adequado para esse cenário.