Documentação HorusBI
Buscar K

Aparência

Abrir no Claude Abrir no ChatGPT

Especificação Completa ​

Esta página contém a especificação completa da API REST do HorusBI no formato interativo.

v1.0.1

HorusBI API​

Baixar Documento OpenAPI

API REST para integração com a plataforma HorusBI.

Autenticação

A API usa dois níveis de tokens Bearer:

Token Header Uso
Client Token Authorization: Bearer <token> Gerenciar múltiplos tenants
Tenant Token Authorization: Bearer <token> Operar dentro de um tenant específico

Modelo de Permissões

O acesso a dados é controlado via Datamarts com permissões granulares:

  • Por Tabela: Acesso individual a cada tabela
  • Por Coluna: Colunas sensíveis podem ser ocultadas
  • Por Linha (RLS): Filtros restringem registros visíveis
  • Por Tempo: Acessos temporários com expiração automática

Servidores​

https://api.horusbi.com.br/v1

Tenants​

Gerenciamento de tenants (ambientes isolados de clientes)

Operações​

GET/tenantsPUT/tenantsPOST/tenantsDELETE/tenantsPOST/tenants/deleteGET/tenants/templates

Listar tenants​

GET
/tenants

Retorna todos os tenants vinculados ao cliente autenticado.

Modelo de Autenticação

A API utiliza dois níveis de autenticação:

Token Escopo Endpoints
Client Token Gerenciar tenants /tenants/*
Tenant Token Gerenciar recursos do tenant /tenant/*

Importante: O campo token retornado para cada tenant é o Tenant Token que deve ser usado para autenticar nos endpoints /tenant/* (usuários, grupos, etc).

Fluxo de Integração

1. Use seu Client Token para chamar GET /tenants
2. Receba a lista de tenants, cada um com seu 'token' individual
3. Use o 'token' do tenant desejado como Bearer para endpoints /tenant/*

Campos Retornados

Campo Descrição
id ID interno do tenant
nome Nome do tenant
token Tenant Token para autenticar em /tenant/*
dominio Domínio de acesso (ex: empresa.horusbi.com.br)
ativo Se o tenant está ativo
development_variables Variáveis globais do ETL
config Configurações do tenant
dw_desks, bi_desks Mesas de dados e BI
bi_apps Aplicações DataViz
dw_tables Tabelas do Data Warehouse
sys_users_tenants Usuários vinculados

Autorizações​

clientBearerAuth

Token de acesso do cliente

TipoHTTP (bearer)

Respostas​

Lista de tenants retornada com sucesso

application/json
JSON
{
"status": "success",
"data": [
{
"id": 1,
"nome": "Empresa ABC",
"token": "tk_abc123...",
"dominio": "abc.horusbi.com.br",
"ativo": true,
"development_variables": {
"db_host": "192.168.1.100",
"environment": "production"
},
"dw_desks": [
{
"id": 1,
"nome": "Mesa Principal"
}
],
"bi_apps": [
{
"id": 10,
"nome": "Dashboard Vendas",
"deskId": 1
}
],
"sys_users_tenants": [
{
"ultimo_login": "2024-12-16T10:00:00Z",
"user": {
"id": 1,
"login": "admin@empresa.com",
"nome": "Administrador"
}
}
]
}
]
}

Playground​

Autorização

Exemplos​

Atualizar tenant​

PUT
/tenants

Atualiza os dados de um tenant existente.

Comportamento

  • Apenas campos enviados serão atualizados
  • O campo id é obrigatório para identificar o tenant
  • Alterações em development_variables são registradas em histórico

Campos Atualizáveis

Campo Descrição
nome Nome do tenant
ativo Status ativo/inativo
dominio Domínio de acesso
development_variables Variáveis globais do ETL
config Configurações do tenant

Mensagens de Erro

Mensagem Causa
Tenant not found ID não existe ou não pertence ao cliente
Invalid development_variables format... Formato incorreto das variáveis

Autorizações​

clientBearerAuth

Token de acesso do cliente

TipoHTTP (bearer)

Corpo da Requisição​

application/json
JSON
{
"id": 1,
"nome": "Empresa ABC Ltda",
"ativo": true
}

Respostas​

Tenant atualizado com sucesso

application/json
JSON
{
"status": "success",
"data": null
}

Playground​

Autorização
Corpo

Exemplos​

Criar tenant​

POST
/tenants

Cria um novo tenant vinculado ao cliente autenticado.

Comportamento

  1. O tenant é criado e vinculado ao cliente do token
  2. Se templateId for informado, o template é aplicado automaticamente
  3. Se não informar templateId, usa o template padrão do cliente (se configurado)
  4. Um Tenant Token é gerado automaticamente e retornado

Variáveis de Desenvolvimento

O campo development_variables armazena variáveis globais usadas pelo ETL.
Aceita dois formatos:

Formato objeto (recomendado):

{
  "db_host": "192.168.1.100",
  "api_key": "abc123"
}

Formato array:

[
  {"key": "db_host", "value": "192.168.1.100"},
  {"key": "api_key", "value": "abc123"}
]

Mensagens de Erro

Mensagem Causa
Invalid development_variables format... Formato incorreto das variáveis

Autorizações​

clientBearerAuth

Token de acesso do cliente

TipoHTTP (bearer)

Corpo da Requisição​

application/json
JSON
{
"nome": "Nova Empresa",
"ativo": true
}

Respostas​

Tenant criado com sucesso

application/json
JSON
{
"status": "success",
"data": {
"id": 10,
"nome": "Nova Empresa",
"token": "tk_xyz789...",
"dominio": "empresa.horusbi.com.br",
"ativo": true
}
}

Playground​

Autorização
Corpo

Exemplos​

Excluir tenant​

DELETE
/tenants

Exclui permanentemente o tenant (soft delete).

Comportamento

  • O tenant é marcado como excluído (soft delete) e fica inacessível
  • A cobrança é encerrada na próxima competência
  • Se o tenant foi excluído durante o mês corrente, ainda será cobrado
    neste mês (última cobrança)
  • Para apenas bloquear o login sem afetar a cobrança, use PUT /tenants
    com ativo: false

Mensagens de Erro

Mensagem Causa
Tenant not found ID não existe ou não pertence ao cliente

Compatibilidade: Clientes que não suportam o método HTTP DELETE
podem usar POST /tenants/delete com o mesmo payload e comportamento.

Autorizações​

clientBearerAuth

Token de acesso do cliente

TipoHTTP (bearer)

Corpo da Requisição​

application/json
JSON
{
"id": 1
}

Respostas​

Tenant excluído com sucesso

application/json
JSON
{
"status": "success",
"data": null
}

Playground​

Autorização
Corpo

Exemplos​

Excluir tenant (compatibilidade)​

POST
/tenants/delete

Alternativa via POST ao DELETE /tenants, para clientes que não
suportam o método HTTP DELETE. Mesmo payload e comportamento —
consulte DELETE /tenants para detalhes de cobrança e soft delete.

Autorizações​

clientBearerAuth

Token de acesso do cliente

TipoHTTP (bearer)

Corpo da Requisição​

application/json
JSON
{
"id": 1
}

Respostas​

Tenant excluído com sucesso

application/json
JSON
{
"status": "success",
"data": true
}

Playground​

Autorização
Corpo

Exemplos​

Listar templates​

GET
/tenants/templates

Retorna os templates disponíveis para o cliente autenticado.

Templates são configurações pré-definidas que podem ser aplicadas
a novos tenants para criar estruturas iniciais de dados, aplicações
e dashboards.

Uso dos Templates

  • Use o id do template no campo templateId ao criar um tenant
  • Templates são aplicados automaticamente na criação
  • Também podem ser aplicados posteriormente via POST /tenant/templates/apply

Autorizações​

clientBearerAuth

Token de acesso do cliente

TipoHTTP (bearer)

Respostas​

Lista de templates retornada com sucesso

application/json
JSON
{
"status": "success",
"data": [
{
"id": 1,
"nome": "Template Varejo"
},
{
"id": 2,
"nome": "Template Financeiro"
},
{
"id": 3,
"nome": "Template Logística"
}
]
}

Playground​

Autorização

Exemplos​

Tenant​

Operações​

GET/tenant

Obter dados do tenant​

GET
/tenant

Retorna os dados completos do tenant autenticado.

Este endpoint retorna as mesmas informações de um tenant individual
que seriam retornadas no GET /tenants, porém usando o Tenant Token
ao invés do Client Token.

Uso Comum

  • Obter informações do tenant a partir do próprio token
  • Verificar recursos disponíveis (mesas, apps, tabelas)
  • Consultar variáveis de desenvolvimento

Campos Retornados

Campo Descrição
id ID interno do tenant
nome Nome do tenant
token Tenant Token (confirmação)
dominio Domínio de acesso
ativo Status ativo/inativo
development_variables Variáveis globais do ETL
config Configurações do tenant
dw_desks Mesas de Data Warehouse
bi_desks Mesas de Business Intelligence
bi_apps Aplicações DataViz
dw_tables Tabelas (resumo)
sys_users_tenants Usuários vinculados

Autorizações​

tenantBearerAuth

Token de acesso do tenant

TipoHTTP (bearer)

Respostas​

Dados do tenant retornados com sucesso

application/json
JSON
{
"status": "success",
"data": {
"id": 1,
"nome": "Empresa ABC",
"token": "tk_abc123...",
"dominio": "abc.horusbi.com.br",
"ativo": true,
"development_variables": {
"db_host": "192.168.1.100",
"db_user": "etl_user"
},
"config": {
"features": {
"enable_ai": true
}
},
"dw_desks": [
{
"id": 1,
"nome": "Mesa DW Principal"
}
],
"bi_desks": [
{
"id": 1,
"nome": "Mesa BI Principal"
}
],
"bi_apps": [
{
"id": 10,
"nome": "Dashboard Vendas",
"deskId": 1
},
{
"id": 11,
"nome": "Dashboard Financeiro",
"deskId": 1
}
],
"dw_tables": [
{
"id": 100,
"nome": "fat_vendas",
"deskId": 1
},
{
"id": 101,
"nome": "dim_produto",
"deskId": 1
}
],
"sys_users_tenants": [
{
"ultimo_login": "2024-12-16T10:00:00Z",
"user": {
"id": 1,
"login": "admin@empresa.com",
"nome": "Administrador"
}
}
]
}
}

Playground​

Autorização

Exemplos​

Tabelas​

Operações​

GET/tenant/tables

Listar tabelas​

GET
/tenant/tables

Retorna todas as tabelas do Data Warehouse do tenant com seus metadados de colunas.

Uso Comum

  • Descobrir tabelas disponíveis para consulta
  • Obter schema das tabelas (colunas e tipos)
  • Construir queries dinâmicas baseadas nos metadados

Campos Retornados

Tabela

Campo Descrição
id ID da tabela
nome Nome técnico da tabela (ex: fat_vendas)
columns Lista de colunas da tabela

Coluna

Campo Descrição
id ID da coluna
column_name Nome técnico da coluna
data_type Tipo de dado (STRING, NUMBER, DATE)
label Rótulo amigável para exibição
column_type Classificação: column, expression

Column Types

Tipo Descrição
column Coluna física da tabela
expression Expressão para cálculos (ex: margem)

Autorizações​

tenantBearerAuth

Token de acesso do tenant

TipoHTTP (bearer)

Respostas​

Lista de tabelas retornada com sucesso

application/json
JSON
{
"status": "success",
"data": [
{
"id": 100,
"nome": "fat_vendas",
"columns": [
{
"id": 1001,
"column_name": "data_venda",
"data_type": "DATE",
"label": "Data da Venda",
"column_type": "column"
},
{
"id": 1002,
"column_name": "valor_total",
"data_type": "NUMBER",
"label": "Valor Total",
"column_type": "column"
},
{
"id": 1003,
"column_name": "produto_id",
"data_type": "NUMBER",
"label": "Produto",
"column_type": "column"
}
]
},
{
"id": 101,
"nome": "dim_produto",
"columns": [
{
"id": 1010,
"column_name": "id",
"data_type": "NUMBER",
"label": "ID",
"column_type": "column"
},
{
"id": 1011,
"column_name": "nome",
"data_type": "STRING",
"label": "Nome do Produto",
"column_type": "column"
},
{
"id": 1012,
"column_name": "margem_calculada",
"data_type": "NUMBER",
"label": "Margem Calculada",
"column_type": "expression"
}
]
}
]
}

Playground​

Autorização

Exemplos​

Listar usuários​

GET
/tenant/users

Retorna todos os usuários ativos vinculados ao tenant autenticado.

Campos Retornados

Campo Descrição
login E-mail/identificador único do usuário
nome Nome de exibição do usuário
ultimo_login Data/hora do último acesso ao tenant
groups IDs dos grupos aos quais o usuário pertence
bi_desks IDs das mesas de BI às quais o usuário tem acesso
apps_deny IDs das aplicações bloqueadas para o usuário
table_restrictions Restrições de dados em tabelas específicas

Nota: Um usuário pode existir em múltiplos tenants. Esta operação retorna apenas os usuários vinculados ao tenant do token.

Autorizações​

tenantBearerAuth

Token de acesso do tenant

TipoHTTP (bearer)

Respostas​

Lista de usuários retornada com sucesso

application/json
JSON
{
"status": "success",
"data": [
{
"id": 1,
"login": "joao.silva@empresa.com",
"nome": "João Silva",
"ultimo_login": "2024-12-16T14:30:00Z",
"groups": [
1,
3
],
"bi_desks": [
5,
8
],
"apps_deny": [
],
"table_restrictions": [
]
},
{
"id": 2,
"login": "maria.santos@empresa.com",
"nome": "Maria Santos",
"ultimo_login": null,
"groups": [
2
],
"bi_desks": [
],
"apps_deny": [
3
],
"table_restrictions": [
{
"tableId": 10,
"filters": "empresa_id = 5"
}
]
}
]
}

Playground​

Autorização

Exemplos​

Editar usuário​

PUT
/tenant/users

Atualiza os dados de um usuário existente no tenant.

Comportamento

  • Apenas campos enviados serão atualizados
  • O campo login é usado como identificador e não pode ser alterado
  • Arrays (groups, bi_desks, etc.) substituem completamente os valores anteriores

Gestão de Permissões

Campo Efeito
groups Define os grupos do usuário (substitui todos)
bi_desks Define acesso às mesas de BI
apps_deny Define aplicações bloqueadas
table_restrictions Define filtros de dados por tabela

Mensagens de Erro

Mensagem Causa
Usuário não encontrado Login não existe ou não está vinculado ao tenant
App {id} não encontrado ID em apps_deny não existe no tenant
Mesa de aplicação {id} não encontrada ID em bi_desks não existe
Tabela {id} não encontrada ID em table_restrictions não existe
Grupo {id} não encontrado ID em groups não existe no tenant

Autorizações​

tenantBearerAuth

Token de acesso do tenant

TipoHTTP (bearer)

Corpo da Requisição​

application/json
JSON
{
"login": "joao@empresa.com",
"nome": "João da Silva Santos"
}

Respostas​

Usuário atualizado com sucesso

application/json
JSON
{
"success": true
}

Playground​

Autorização
Corpo

Exemplos​

Criar usuário​

POST
/tenant/users

Cria um novo usuário ou vincula um usuário existente ao tenant.

Comportamento

  1. Se o login não existe na plataforma → cria novo usuário e vincula ao tenant
  2. Se o login existe mas não está vinculado ao tenant → vincula o usuário existente
  3. Se o login já está vinculado ao tenant → retorna erro

Importante: Usuários são compartilhados entre tenants. Se o login já existe em outro tenant, o mesmo usuário será vinculado (não duplicado).

Campos Opcionais

Após criar o usuário, você pode definir permissões iniciais:

Campo Descrição
groups IDs dos grupos a associar
bi_desks IDs das mesas de BI a liberar
apps_deny IDs das aplicações a bloquear
table_restrictions Filtros de dados por tabela

Mensagens de Erro

Mensagem Causa
Login já está cadastrado Usuário já vinculado ao tenant
App {id} não encontrado ID em apps_deny não existe
Mesa de aplicação {id} não encontrada ID em bi_desks não existe
Tabela {id} não encontrada ID em table_restrictions não existe
Grupo {id} não encontrado ID em groups não existe

Autorizações​

tenantBearerAuth

Token de acesso do tenant

TipoHTTP (bearer)

Corpo da Requisição​

application/json
JSON
{
"login": "novo.usuario@empresa.com"
}

Respostas​

Operação processada

application/json
JSON
{
"success": true
}

Playground​

Autorização
Corpo

Exemplos​

Inativar usuário​

DELETE
/tenant/users/delete

Remove o vínculo de um usuário com o tenant (soft delete).

Comportamento

  • O usuário é desvinculado do tenant, não excluído da plataforma
  • Se o usuário estiver vinculado a outros tenants, continua ativo neles
  • Todas as permissões específicas do tenant são preservadas (caso reativado)
  • O registro de ultimo_login é mantido para auditoria

Mensagens de Erro

Mensagem Causa
Usuário não encontrado Login não existe ou não está vinculado ao tenant

Autorizações​

tenantBearerAuth

Token de acesso do tenant

TipoHTTP (bearer)

Corpo da Requisição​

application/json
JSON
{
"login": "usuario.inativo@empresa.com"
}

Respostas​

Operação processada

application/json
JSON
{
"success": true
}

Playground​

Autorização
Corpo

Exemplos​

Salvar permissões do grupo​

POST
/tenant/groups/functions

Configura as permissões de acesso a funções do sistema para um grupo específico.

Modelo de Permissões

O sistema utiliza um modelo RBAC (Role-Based Access Control) onde:

  • Suites controlam acesso às áreas do sistema (DW, HEC, BI, ETL)
  • Funções controlam ações específicas dentro de cada suite
  • Permissões definem o nível de acesso (ler, criar, editar, excluir, publicar)

Comportamento

  1. O grupo precisa ter acesso à suite antes de configurar permissões de funções
  2. Se read = false, todas as outras permissões são automaticamente desabilitadas
  3. Permissões não enviadas na permissionMatrix são removidas (soft delete)
  4. Funções com alias inválido são ignoradas silenciosamente

Hierarquia de Permissões

Permissão Descrição Depende de
read Visualizar o recurso -
create Criar novos recursos read
update Editar recursos existentes read
delete Excluir recursos read
publish Publicar/disponibilizar recursos read
is_blocked Bloqueia completamente o acesso -

Suites Disponíveis

Alias Descrição
dw Data Warehouse - Modelagem e tabelas
bi Business Intelligence - DataViz e dashboards
etl ETL - Fluxos de dados
hec HEC - Controle empresarial

Mensagens de Erro

Mensagem Causa
Tenant não encontrado Token inválido ou tenant inativo
Grupo não encontrado ID não existe ou não pertence ao tenant

Autorizações​

tenantBearerAuth

Token de acesso do tenant

TipoHTTP (bearer)

Corpo da Requisição​

application/json
JSON
{
"groupId": 1,
"suites": [
{
"alias": "bi"
},
{
"alias": "dw"
}
]
}

Respostas​

Permissões configuradas

application/json
JSON
{
"status": "success",
"data": {
"success": true
}
}

Playground​

Autorização
Corpo

Exemplos​

Listar permissões do grupo​

POST
/tenant/groups/functions/list

Retorna todas as permissões de funções configuradas para um grupo, incluindo as funções disponíveis mas ainda não configuradas.

Comportamento

  1. Retorna as suites às quais o grupo tem acesso
  2. Retorna todas as funções das suites habilitadas
  3. Funções não configuradas aparecem com todas as permissões como false
  4. Resultado é ordenado por suite_alias e depois por alias

Campos Retornados

Suites

Array com os aliases das suites habilitadas para o grupo.

Permissions

Campo Descrição
alias Identificador único da função
nome Nome amigável da função
suite_alias Suite à qual a função pertence
read Permissão de leitura
create Permissão de criação
update Permissão de edição
delete Permissão de exclusão
publish Permissão de publicação
is_blocked Se a função está bloqueada

Mensagens de Erro

Mensagem Causa
Grupo não encontrado ID não existe ou não pertence ao tenant

Autorizações​

tenantBearerAuth

Token de acesso do tenant

TipoHTTP (bearer)

Corpo da Requisição​

application/json
JSON
{
"groupId": 1
}

Respostas​

Permissões do grupo

application/json
JSON
{
"status": "success",
"data": {
"success": true,
"data": {
"suites": [
"bi",
"dw"
],
"permissions": [
{
"alias": "bi_app",
"nome": "Aplicações BI",
"suite_alias": "bi",
"read": true,
"create": true,
"update": true,
"delete": false,
"publish": true,
"is_blocked": false
},
{
"alias": "bi_dashboard",
"nome": "Dashboards",
"suite_alias": "bi",
"read": true,
"create": false,
"update": false,
"delete": false,
"publish": false,
"is_blocked": false
},
{
"alias": "dw_table",
"nome": "Tabelas DW",
"suite_alias": "dw",
"read": true,
"create": true,
"update": true,
"delete": true,
"publish": false,
"is_blocked": false
}
]
}
}
}

Playground​

Autorização
Corpo

Exemplos​

Listar grupos​

GET
/tenant/groups

Retorna todos os grupos ativos do tenant com seus membros e permissões.

O que são Grupos?

Grupos são conjuntos de permissões que podem ser atribuídos a múltiplos usuários.
Isso simplifica a gestão de acesso, pois ao invés de configurar permissões
individualmente para cada usuário, você configura uma vez no grupo.

Herança de Permissões

Um usuário herda as permissões de todos os grupos aos quais pertence:

  • Se pertence a um grupo com acesso à Mesa A, terá acesso à Mesa A
  • Se pertence a um grupo com app X bloqueado, terá app X bloqueado

Importante: Permissões individuais do usuário podem sobrescrever as do grupo.

Campos Retornados

Campo Descrição
id ID do grupo
nome Nome do grupo
bi_desks IDs das mesas de BI liberadas
apps_deny IDs das aplicações bloqueadas
table_restrictions Restrições de dados por tabela
users IDs dos usuários membros

Autorizações​

tenantBearerAuth

Token de acesso do tenant

TipoHTTP (bearer)

Respostas​

Lista de grupos retornada com sucesso

application/json
JSON
{
"status": "success",
"data": [
{
"id": 1,
"nome": "Administradores",
"bi_desks": [
1,
2,
3
],
"apps_deny": [
],
"table_restrictions": [
],
"users": [
1,
5,
8
]
},
{
"id": 2,
"nome": "Analistas Regionais",
"bi_desks": [
1
],
"apps_deny": [
5,
6
],
"table_restrictions": [
{
"tableId": 10,
"filters": "regiao = 'Sul'"
}
],
"users": [
2,
3,
4
]
},
{
"id": 3,
"nome": "Visualizadores",
"bi_desks": [
1
],
"apps_deny": [
2,
3,
4,
5,
6
],
"table_restrictions": [
],
"users": [
6,
7
]
}
]
}

Playground​

Autorização

Exemplos​

Editar grupo​

PUT
/tenant/groups

Atualiza os dados de um grupo existente.

Comportamento

  • O campo id é obrigatório para identificar o grupo
  • Apenas campos enviados serão atualizados
  • Arrays (bi_desks, apps_deny, etc.) substituem completamente os valores anteriores
  • Para adicionar um usuário, envie a lista completa com o novo usuário incluído
  • Para remover um usuário, envie a lista sem ele

Gestão de Usuários

O campo users recebe um array de logins (e-mails) dos usuários:

  • Usuários são identificados pelo login, não pelo ID
  • Apenas usuários vinculados ao tenant podem ser adicionados
  • Usuários não encontrados geram erro

Gestão de Acessos

Campo Efeito
bi_desks Define acesso às mesas de BI (por ID)
apps_deny Define aplicações bloqueadas (por ID)
table_restrictions Define filtros de dados por tabela

Mensagens de Erro

Mensagem Causa
ID do grupo é obrigatório Campo id não enviado
Grupo não encontrado ID não existe ou não pertence ao tenant
App {id} não encontrado ID em apps_deny não existe
Mesa de aplicação {id} não encontrada ID em bi_desks não existe
Tabela {id} não encontrada ID em table_restrictions não existe
Usuário {login} não encontrado Login não existe ou não vinculado ao tenant

Autorizações​

tenantBearerAuth

Token de acesso do tenant

TipoHTTP (bearer)

Corpo da Requisição​

application/json
JSON
{
"id": 1,
"nome": "Administradores Gerais"
}

Respostas​

Operação processada

application/json
JSON
{
"success": true
}

Playground​

Autorização
Corpo

Exemplos​

Criar grupo​

POST
/tenant/groups

Cria um novo grupo no tenant.

Comportamento

  1. O campo nome é obrigatório e não pode estar vazio
  2. O campo id não deve ser enviado (será gerado automaticamente)
  3. Após criar o grupo, você pode definir permissões iniciais
  4. O grupo é criado e depois atualizado com as permissões via EditGroup

Configuração Inicial

Ao criar um grupo, você pode já definir:

Campo Descrição
bi_desks Mesas de BI a liberar
apps_deny Aplicações a bloquear
table_restrictions Filtros de dados iniciais
users Usuários a adicionar ao grupo (por login)

Mensagens de Erro

Mensagem Causa
Não é possível criar um grupo com um ID específico Campo id foi enviado
Nome do grupo é obrigatório Campo nome vazio ou não enviado
App {id} não encontrado ID em apps_deny não existe
Mesa de aplicação {id} não encontrada ID em bi_desks não existe
Usuário {login} não encontrado Login não vinculado ao tenant

Autorizações​

tenantBearerAuth

Token de acesso do tenant

TipoHTTP (bearer)

Corpo da Requisição​

application/json
JSON
{
"nome": "Novo Grupo"
}

Respostas​

Operação processada

application/json
JSON
{
"success": true
}

Playground​

Autorização
Corpo

Exemplos​

Inativar grupo​

POST
/tenant/groups/delete

Remove um grupo do tenant (soft delete).

Comportamento

  • O grupo é inativado, não excluído permanentemente
  • Usuários do grupo perdem as permissões herdadas imediatamente
  • As permissões individuais dos usuários não são afetadas
  • O grupo pode ser reativado posteriormente (via suporte)

Impacto nos Usuários

Quando um grupo é inativado:

  1. Todos os membros perdem as permissões do grupo
  2. Se um usuário só tinha acesso via grupo, perde o acesso
  3. Permissões de outros grupos não são afetadas

Mensagens de Erro

Mensagem Causa
ID do grupo é obrigatório Campo id não enviado
Grupo não encontrado ID não existe ou já está inativo

Autorizações​

tenantBearerAuth

Token de acesso do tenant

TipoHTTP (bearer)

Corpo da Requisição​

application/json
JSON
{
"id": 3
}

Respostas​

Operação processada

application/json
JSON
{
"success": true
}

Playground​

Autorização
Corpo

Exemplos​

Autenticação​

Operações​

POST/tenant/login

Gerar token de login transparente​

POST
/tenant/login

Gera um token JWT temporário para login transparente (SSO) de um usuário no BI.

Caso de Uso Principal

Este endpoint permite login transparente (Single Sign-On) onde o usuário
é autenticado no seu sistema e redirecionado automaticamente para o BI sem
precisar digitar credenciais novamente.

Validade do Token

Propriedade Valor
Tempo de expiração 1 hora
Uso único Não (pode ser reutilizado até expirar)
Tipo JWT assinado

Importante: O token expira em 1 hora. Gere um novo token a cada sessão do usuário para garantir segurança.

Campos Retornados

Campo Descrição
success Se a operação foi bem sucedida
token Token JWT para autenticação
url URL pronta para redirecionamento/embed

Métodos de Integração

1. Iframe (Embed)

Ideal para embutir o BI dentro do seu sistema:

<iframe src="https://[dominio]/auth/api/[token]?showMenu=0" 
        width="100%" height="600px"></iframe>

2. Redirecionamento

Redirecione o usuário para a URL retornada:

window.location.href = response.url;

3. WebView (Mobile/Desktop)

Use a URL em componentes nativos como WebView.

Parâmetros de URL

A URL retornada aceita query parameters para customização:

Parâmetro Valores Descrição
showMenu 0 / 1 Exibe ou oculta o menu principal
showDesksIcon 0 / 1 Exibe ou oculta o ícone de mesas (padrão: 1)
ref Base64 Redireciona para uma rota específica após login

Deep Linking com ref

Para redirecionar o usuário diretamente para uma página específica:

  1. Codifique a rota em Base64 (ex: /app/report/1 → L2FwcC9yZXBvcnQvMQ==)
  2. Adicione como parâmetro ref na URL

Exemplo:

https://[dominio]/auth/api/[token]?showMenu=0&ref=L2FwcC9yZXBvcnQvMQ==

Fluxo de Integração Completo

1. Usuário faz login no SEU sistema
2. Seu backend chama POST /tenant/login com o email do usuário
3. Recebe token e URL
4. Exibe iframe ou redireciona o usuário
5. Usuário acessa o BI já autenticado

Construindo Menu Customizado

Quando usar showMenu=0, você pode criar um menu customizado:

  1. Use GET /tenant para listar aplicações e mesas
  2. Use GET /tenant/users para consultar permissões do usuário
  3. Monte links no formato: https://[dominio]/auth/api/[token]?showMenu=0&ref=[base64]

Mensagens de Erro

Mensagem Causa
Usuário não encontrado Login não existe ou não está vinculado ao tenant

Autorizações​

tenantBearerAuth

Token de acesso do tenant

TipoHTTP (bearer)

Corpo da Requisição​

application/json
JSON
{
"login": "joao.silva@empresa.com"
}

Respostas​

Operação processada

application/json
JSON
{
"success": true,
"token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...",
"url": "https://empresa.horusbi.com.br/auth/api/eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...?showMenu=0"
}

Playground​

Autorização
Corpo

Exemplos​

Aplicar template ao tenant​

POST
/tenant/templates/apply

Aplica um template pré-configurado ao tenant, criando estruturas de dados, aplicações e dashboards.

O que são Templates?

Templates são configurações pré-definidas que incluem:

  • Estruturas de tabelas do Data Warehouse
  • Aplicações DataViz
  • Dashboards e widgets pré-configurados
  • Fluxos ETL (dataflows)
  • Conexões de dados

Templates permitem provisionar rapidamente novos tenants com estruturas prontas para uso.

Comportamento

  1. Valida se o tenant existe e está ativo
  2. Valida se o template existe
  3. Aplica todas as estruturas do template ao tenant
  4. Recursos já existentes serão sobreescritos

Importante: Por padrão o apply é aditivo - adiciona recursos ao tenant sem remover os existentes. Com espelhar=true, ele também poda o conteúdo de produto órfão (fora do template), deixando o tenant no estado canônico; use dryRun=true para pré-visualizar a poda antes.

Recarga pós-apply (reloadPlan)

Quando o apply reconstrói ou cria tabelas, elas ficam vazias até a próxima carga. A resposta traz um reloadPlan (tabelas afetadas em ordem de dependência). Dispare as cargas imediatamente via POST /tenant/templates/reload passando esses itens.

Quando Usar

Cenário Uso Recomendado
Novo tenant Use templateId na criação (POST /tenants)
Tenant existente Use este endpoint
Atualização de template Reaplicar para obter novas versões

Obtendo Templates Disponíveis

Use o endpoint GET /tenants/templates para listar os templates disponíveis para seu cliente.

Mensagens de Erro

Mensagem Causa
Tenant not found Tenant não existe ou foi excluído
Template not found Template não existe ou não pertence ao cliente

Autorizações​

tenantBearerAuth

Token de acesso do tenant

TipoHTTP (bearer)

Corpo da Requisição​

application/json
JSON
{
"templateId": 5
}

Respostas​

Operação processada

application/json
JSON
{
"success": true,
"reloadPlan": [
{
"flowId": 39562,
"tableId": 56587,
"tableName": "RAW - Oportunidades",
"tokenId": 591,
"reason": "rebuilt",
"agentOnline": true
}
]
}

Playground​

Autorização
Corpo

Exemplos​

Disparar recarga das tabelas pós-apply​

POST
/tenant/templates/reload

Dispara, em lote e em ordem de dependência, as cargas dos flows do reloadPlan
devolvido por POST /tenant/templates/apply. Use quando o apply reconstruiu/criou
tabelas (que ficam vazias até a próxima carga) e você quer populá-las imediatamente.

O backend agrupa por agente e enfileira as cargas; agentes offline são pulados
(skipped_offline) sem abortar o lote.

Autorizações​

tenantBearerAuth

Token de acesso do tenant

TipoHTTP (bearer)

Corpo da Requisição​

application/json
JSON
{
"items": [
{
"flowId": 39562,
"tokenId": 591,
"context": "Total"
}
]
}

Respostas​

Lote enfileirado

application/json
JSON
{
"success": true,
"results": [
{
"tokenId": 591,
"tenantId": 773,
"status": "enqueued"
}
]
}

Playground​

Autorização
Corpo

Exemplos​

Flows​

Operações​

GET/tenant/flowsPOST/tenant/flows/run

Listar fluxos ETL​

GET
/tenant/flows

Retorna todos os fluxos ETL (dataflows) ativos do tenant.

O que são Flows?

Flows (ou Dataflows) são pipelines de dados configurados no Horus ETL.
Cada flow define uma sequência de operações para extrair, transformar
e carregar dados no Data Warehouse.

Campos Retornados

Campo Descrição
id ID do flow
nome Nome do flow
deskId Mesa de dados à qual pertence
tableId Tabela de destino (quando aplicável)
load_type Tipo de carga: full ou incremental
versao Versão atual do flow

Tipos de Carga (load_type)

Tipo Descrição
Total Substitui todos os dados a cada execução
Incremental Adiciona apenas dados novos/alterados
Temporal Carrega dados de um período específico

Autorizações​

tenantBearerAuth

Token de acesso do tenant

TipoHTTP (bearer)

Respostas​

Lista de fluxos retornada com sucesso

application/json
JSON
{
"status": "success",
"data": [
{
"id": 1,
"nome": "Carga Vendas Diária",
"deskId": 1,
"tableId": 100,
"load_type": "Incremental",
"versao": 5
},
{
"id": 2,
"nome": "Carga Produtos Full",
"deskId": 1,
"tableId": 101,
"load_type": "Total",
"versao": 2
},
{
"id": 3,
"nome": "Carga Temporal Mensal",
"deskId": 1,
"tableId": 102,
"load_type": "Temporal",
"versao": 1
}
]
}

Playground​

Autorização

Exemplos​

Executar fluxo manualmente​

POST
/tenant/flows/run

Força a execução imediata de um flow específico.

Comportamento

  1. Valida se o flow existe e está ativo
  2. Envia comando de execução para o agente ETL
  3. Retorna imediatamente (execução é assíncrona)

Importante: A execução é assíncrona. O retorno success: true indica
que o comando foi enviado, não que o flow foi concluído.

Parâmetro Context

O campo context é obrigatório e define o modo de carga do flow:

Context Descrição
Total Carga total - substitui todos os dados
Incremental Carga incremental - apenas novos/alterados
Temporal:* Carga temporal - período específico

Formatos Temporais

Para cargas temporais, use o formato Temporal:tipo:valor:

Formato Exemplo Descrição
Temporal:Days:N Temporal:Days:30 Últimos N dias
Temporal:Future:N Temporal:Future:7 Próximos N dias
Temporal:Year:AAAA Temporal:Year:2024 Ano específico
Temporal:Month:MM-AAAA Temporal:Month:01-2024 Mês específico

Mensagens de Erro

Mensagem Causa
Flow não encontrado ID não existe ou flow está inativo

Autorizações​

tenantBearerAuth

Token de acesso do tenant

TipoHTTP (bearer)

Corpo da Requisição​

application/json
JSON
{
"flowId": 1,
"context": "Total"
}

Respostas​

Comando de execução enviado

application/json
JSON
{
"status": "success",
"data": true
}

Playground​

Autorização
Corpo

Exemplos​

Listar agendamentos ETL​

GET
/tenant/etl-schedules

Retorna todos os agendamentos (schedules) do tenant com seus flows e triggers.

O que são Schedules?

Schedules são agendamentos de execução que definem quando e como os flows
devem ser executados automaticamente. Um schedule pode conter múltiplos flows
que serão executados em sequência.

Campos Retornados

Campo Descrição
id ID do agendamento
nome Nome do agendamento
ativo Se o agendamento está ativo
flows Lista de flows vinculados (em ordem de execução)
triggers Configurações de gatilho (quando executar)

Campos do Trigger

Campo Descrição
type Tipo de trigger (timer, cron, etc.)
period Intervalo em minutos (para triggers periódicos)
start_time Hora de início (HH:MM)
end_time Hora de término (HH:MM)
start_when Data/hora de início do agendamento

Autorizações​

tenantBearerAuth

Token de acesso do tenant

TipoHTTP (bearer)

Respostas​

Lista de agendamentos retornada com sucesso

application/json
JSON
{
"status": "success",
"data": [
{
"id": 1,
"nome": "Carga Diária 6h",
"ativo": true,
"flows": [
{
"flowId": 1
},
{
"flowId": 2
}
],
"triggers": [
{
"type": "timer",
"period": 1440,
"start_time": "06:00",
"end_time": null,
"start_when": "2024-01-01T06:00:00Z"
}
]
},
{
"id": 2,
"nome": "Carga Horária",
"ativo": true,
"flows": [
{
"flowId": 3
}
],
"triggers": [
{
"type": "timer",
"period": 60,
"start_time": "08:00",
"end_time": "20:00",
"start_when": null
}
]
}
]
}

Playground​

Autorização

Exemplos​

Executar agendamento manualmente​

POST
/tenant/etl-schedules/run

Força a execução imediata de um agendamento, executando todos os seus flows em sequência.

Comportamento

  1. Valida se o schedule existe
  2. Envia comando de execução para o agente ETL
  3. Retorna imediatamente (execução é assíncrona)
  4. Flows são executados em ordem conforme configurado no schedule

Importante: A execução é assíncrona. O retorno success: true indica
que o comando foi enviado, não que todos os flows foram concluídos.

Diferença entre RunFlow e RunSchedule

RunFlow RunSchedule
Executa um único flow Executa todos os flows do schedule
Não respeita ordem Respeita ordem de execução
Requer context Usa context interno

Mensagens de Erro

Mensagem Causa
Schedule não encontrado ID não existe ou foi excluído

Autorizações​

tenantBearerAuth

Token de acesso do tenant

TipoHTTP (bearer)

Corpo da Requisição​

application/json
JSON
{
"scheduleId": 1
}

Respostas​

Comando de execução enviado

application/json
JSON
{
"status": "success",
"data": true
}

Playground​

Autorização
Corpo

Exemplos​

Listar datamarts do tenant​

GET
/tenant/datamart

Retorna todos os datamarts do tenant com suas tabelas e responsáveis.

O que são Datamarts?

Datamarts são Vitrines de Negócio que organizam tabelas por contexto de uso,
não por onde estão armazenadas. Eles permitem:

  • Governança descentralizada: Cada área de negócio gerencia seus próprios acessos
  • Segurança granular: Controle de permissões por tabela, usuário e grupo
  • Organização lógica: Uma tabela pode aparecer em múltiplos datamarts

Analogia: Pense no Spotify - a música está gravada no álbum do artista (Mesa),
mas você pode adicioná-la em várias playlists diferentes (Datamarts).

Estrutura Hierárquica

Conceito Função Gerenciado por
Mesa (Desk) Armazenamento físico Engenharia de Dados
Datamart Organização de negócio Dono do Datamart
Permissão Controle de acesso Dono do Datamart

Campos Retornados

Campo Descrição
id ID do datamart
nome Nome do datamart (ex: "Vendas", "RH", "Financeiro")
dm_tables Lista de tabelas vinculadas ao datamart
owners Lista de usuários responsáveis pelo datamart

Fluxo de Uso Típico

  1. Use este endpoint para listar datamarts do tenant
  2. Use /tenant/datamart/{id}/user para ver permissões de usuários
  3. Use /tenant/datamart/{id}/group para ver permissões de grupos

Autorizações​

tenantBearerAuth

Token de acesso do tenant

TipoHTTP (bearer)

Respostas​

Lista de datamarts retornada com sucesso

application/json
JSON
{
"status": "success",
"data": [
{
"id": 1,
"nome": "Comercial",
"dm_tables": [
{
"tableId": 10,
"table": {
"id": 10,
"nome": "Vendas",
"columns": [
{
"id": 100,
"column_name": "valor",
"data_type": "numeric",
"label": "Valor da Venda"
}
]
}
}
],
"owners": [
{
"userId": 5,
"user": {
"id": 5,
"nome": "João Silva",
"login": "joao.silva@empresa.com"
}
}
]
},
{
"id": 2,
"nome": "RH",
"dm_tables": [
{
"tableId": 20,
"table": {
"id": 20,
"nome": "Funcionários",
"columns": [
{
"id": 200,
"column_name": "salario",
"data_type": "numeric",
"label": "Salário"
}
]
}
}
],
"owners": [
{
"userId": 6,
"user": {
"id": 6,
"nome": "Maria Santos",
"login": "maria.santos@empresa.com"
}
}
]
}
]
}

Playground​

Autorização

Exemplos​

Criar ou atualizar datamart​

POST
/tenant/datamart

Cria um novo datamart ou atualiza um existente. O comportamento depende do campo id:

Campo id Comportamento
Ausente Cria novo datamart
Presente Atualiza datamart existente

Criação de Datamart

Para criar um datamart, informe:

  • nome: Nome do datamart (obrigatório)
  • dm_tables: Lista de tabelas a vincular (obrigatório)
  • owners: Lista de usuários responsáveis (obrigatório)

Atualização de Datamart

Na atualização, o sistema:

  • Adiciona tabelas novas que não existiam
  • Remove tabelas que não estão mais na lista
  • Mantém tabelas que continuam na lista

O mesmo comportamento se aplica aos owners.

Obtendo IDs Necessários

Para obter Use o endpoint
IDs de tabelas GET /tenant/data → campo id das tabelas
IDs de usuários GET /tenant/users → campo id dos usuários

Mensagens de Erro

Mensagem Causa
Invalid userId Usuário não existe ou não pertence ao tenant
Invalid tableId Tabela não existe ou foi excluída
Datamart not found ID informado não existe (ao atualizar)

Autorizações​

tenantBearerAuth

Token de acesso do tenant

TipoHTTP (bearer)

Corpo da Requisição​

application/json
JSON
{
"nome": "Vendas Regional",
"dm_tables": [
{
"tableId": 10
},
{
"tableId": 15
}
],
"owners": [
{
"userId": 5
}
]
}

Respostas​

Operação processada com sucesso

application/json
JSON
{
"success": true
}

Playground​

Autorização
Corpo

Exemplos​

Listar permissões de usuários do datamart​

GET
/tenant/datamart/{id}/user

Retorna todas as permissões configuradas para usuários individuais em um datamart.

Modelo de Permissão Granular

No Horus, as permissões de acesso a dados são extremamente granulares:

Nível Descrição
Por Tabela Cada usuário pode ter acesso diferente a cada tabela
Por Coluna Colunas sensíveis podem ser ocultadas
Por Linha Filtros restringem quais registros o usuário vê
Por Tempo Acesso pode ter data de expiração
Por Exportação Controle separado para visualização vs. exportação

Campos Retornados por Permissão

Campo Descrição
userId ID do usuário
user Dados do usuário (id, nome, login)
tableId ID da tabela
table Dados da tabela (id, nome)
allowed Se o usuário pode visualizar a tabela
allow_export Se pode exportar os dados
expires_in Data de expiração do acesso (opcional)
hidden_columns Colunas que o usuário não pode ver
filters Filtros de linha (RLS - Row Level Security)

Exemplo de Caso de Uso

Um vendedor pode:

  • Ver a tabela de Vendas (allowed: true)
  • Exportar apenas relatórios, não dados brutos (allow_export: false)
  • Não ver coluna de margem de lucro (hidden_columns: ["margem"])
  • Ver apenas vendas da sua região (filters: [{column: "regiao", operator: "=", value: "Sul"}])

Nota: Este endpoint retorna permissões por USUÁRIO. Para permissões por grupo,
use GET /tenant/datamart/{id}/group.

Autorizações​

tenantBearerAuth

Token de acesso do tenant

TipoHTTP (bearer)

Parâmetros​

Parâmetros de Caminho

id*

ID do datamart

Tipointeger
Obrigatório
Example1

Respostas​

Lista de permissões de usuários

application/json
JSON
{
"status": "success",
"data": [
{
"userId": 10,
"user": {
"id": 10,
"nome": "Pedro Vendedor",
"login": "pedro@empresa.com"
},
"tableId": 100,
"table": {
"id": 100,
"nome": "Vendas"
},
"allowed": true,
"allow_export": false,
"expires_in": "2025-12-31T23:59:59Z",
"hidden_columns": [
"margem",
"custo"
],
"filters": [
{
"column": "regiao",
"operator": "=",
"value": "Sul"
}
]
},
{
"userId": 11,
"user": {
"id": 11,
"nome": "Maria Gerente",
"login": "maria@empresa.com"
},
"tableId": 100,
"table": {
"id": 100,
"nome": "Vendas"
},
"allowed": true,
"allow_export": true,
"expires_in": null,
"hidden_columns": [
],
"filters": [
]
}
]
}

Playground​

Autorização
Variáveis
Chave
Valor

Exemplos​

Configurar permissão de usuário​

POST
/tenant/datamart/{id}/user

Cria ou atualiza a permissão de um usuário específico para acessar uma tabela do datamart.

Comportamento

Se já existir uma permissão para a combinação (datamart + tabela + usuário):

  • A permissão é atualizada com os novos valores

Caso contrário:

  • Uma nova permissão é criada

Campos de Segurança

allowed (Acesso à Tabela)

Valor Comportamento
true Usuário pode visualizar a tabela
false Usuário NÃO pode ver a tabela (bloqueado)

allow_export (Exportação)

Valor Comportamento
true Usuário pode exportar dados (CSV, Excel)
false Usuário apenas visualiza, não exporta

hidden_columns (Colunas Ocultas)

Lista de nomes de colunas que o usuário não deve ver.
Exemplo: ["salario", "cpf", "endereco"]

filters (Filtros de Linha - RLS)

Filtros que restringem quais registros o usuário pode ver.
Cada filtro tem:

Campo Descrição Exemplo
column Nome da coluna regiao
operator Operador =, !=, >, <, >=, <=, IN
value Valor Sul

Exemplo prático: Um vendedor só vê vendas da sua região:

"filters": [
  {"column": "regiao", "operator": "=", "value": "Sul"}
]

expires_in (Expiração)

Data/hora em que o acesso expira automaticamente.
Útil para acessos temporários (consultores, estagiários).

Mensagens de Erro

Mensagem Causa
Datamart not found ID do datamart não existe
Table not found tableId não existe no tenant
Invalid userId Usuário não existe ou inativo

Autorizações​

tenantBearerAuth

Token de acesso do tenant

TipoHTTP (bearer)

Parâmetros​

Parâmetros de Caminho

id*

ID do datamart

Tipointeger
Obrigatório
Example1

Corpo da Requisição​

application/json
JSON
{
"userId": 10,
"tableId": 100,
"allowed": true,
"allow_export": true,
"expires_in": null,
"hidden_columns": [
],
"filters": [
]
}

Respostas​

Permissão salva com sucesso

application/json
JSON
{
"status": "success",
"data": true
}

Playground​

Autorização
Variáveis
Chave
Valor
Corpo

Exemplos​

Listar permissões de grupos do datamart​

GET
/tenant/datamart/{id}/group

Retorna todas as permissões configuradas para grupos em um datamart.

Diferença entre Usuário e Grupo

Tipo Quando usar
Usuário Permissões específicas para uma pessoa
Grupo Permissões compartilhadas por múltiplos usuários

Recomendação: Use grupos para configuração em massa e usuários
apenas para exceções individuais.

Herança de Permissões

Um usuário recebe a combinação das permissões:

  1. Permissões dos grupos aos quais pertence
  2. Permissões individuais (sobrescrevem grupos)

Campos Retornados

Mesma estrutura do endpoint de usuários, mas com groupId e group em vez de userId e user.

Exemplo de Caso de Uso

O grupo "Vendedores" pode:

  • Ver tabela de Vendas
  • Ver apenas vendas do mês atual (filtro)
  • Não ver margens (hidden_columns)

Depois, vendedores seniores recebem permissão individual para ver margens.

Autorizações​

tenantBearerAuth

Token de acesso do tenant

TipoHTTP (bearer)

Parâmetros​

Parâmetros de Caminho

id*

ID do datamart

Tipointeger
Obrigatório
Example1

Respostas​

Lista de permissões de grupos

application/json
JSON
{
"status": "success",
"data": [
{
"groupId": 5,
"group": {
"id": 5,
"nome": "Vendedores"
},
"tableId": 100,
"table": {
"id": 100,
"nome": "Vendas"
},
"allowed": true,
"allow_export": false,
"expires_in": null,
"hidden_columns": [
"margem",
"custo"
],
"filters": [
{
"column": "data_venda",
"operator": ">=",
"value": "2024-01-01"
}
]
},
{
"groupId": 6,
"group": {
"id": 6,
"nome": "Gerentes"
},
"tableId": 100,
"table": {
"id": 100,
"nome": "Vendas"
},
"allowed": true,
"allow_export": true,
"expires_in": null,
"hidden_columns": [
],
"filters": [
]
}
]
}

Playground​

Autorização
Variáveis
Chave
Valor

Exemplos​

Configurar permissão de grupo​

POST
/tenant/datamart/{id}/group

Cria ou atualiza a permissão de um grupo para acessar uma tabela do datamart.

Comportamento Idêntico ao de Usuário

Este endpoint funciona exatamente como o POST /tenant/datamart/{id}/user,
mas usa groupId em vez de userId.

Vantagens de Usar Grupos

  1. Escalabilidade: Configure uma vez, aplique a muitos usuários
  2. Manutenção: Atualize em um lugar, afete todos os membros
  3. Onboarding: Novos funcionários herdam permissões automaticamente

Campos Aceitos

Campo Tipo Descrição
groupId integer ID do grupo (obrigatório)
tableId integer ID da tabela (obrigatório)
allowed boolean Acesso permitido (obrigatório)
allow_export boolean Pode exportar (obrigatório)
expires_in datetime Expiração (opcional)
hidden_columns string[] Colunas ocultas (opcional)
filters object[] Filtros RLS (opcional)

Mensagens de Erro

Mensagem Causa
Datamart not found ID do datamart não existe
Table not found tableId não existe no tenant
Invalid groupId Grupo não existe ou foi excluído

Autorizações​

tenantBearerAuth

Token de acesso do tenant

TipoHTTP (bearer)

Parâmetros​

Parâmetros de Caminho

id*

ID do datamart

Tipointeger
Obrigatório
Example1

Corpo da Requisição​

application/json
JSON
{
"groupId": 5,
"tableId": 100,
"allowed": true,
"allow_export": false,
"hidden_columns": [
"margem",
"custo"
],
"filters": [
{
"column": "regiao",
"operator": "=",
"value": "Sul"
}
]
}

Respostas​

Permissão de grupo salva com sucesso

application/json
JSON
{
"status": "success",
"data": true
}

Playground​

Autorização
Variáveis
Chave
Valor
Corpo

Exemplos​

Desenvolvido por VitePress OpenAPI