Atenção: este recurso está em fase beta. O funcionamento, schema e cadência podem sofrer ajustes durante o período de validação. Clientes interessados em ativar devem alinhar previamente com o time da Linkana.
Os pipelines de dados são a forma da Linkana entregar dados de fornecedores de maneira recorrente e estruturada para os sistemas de BI, dashboards ou data warehouses do cliente. Em vez de depender de extrações manuais, o pipeline exporta automaticamente os dados para um bucket ou container na cloud do cliente (Google Cloud Storage ou Azure Blob Storage), de onde o time de dados consome com a ferramenta que preferir — BigQuery, Databricks, Power BI, Synapse, Python, entre outras.
O objetivo é que os dados da Linkana estejam disponíveis de forma confiável e padronizada dentro dos fluxos analíticos que já existem na empresa, sem trabalho manual recorrente.
Como funciona
O fluxo de um pipeline tem três etapas:
Extração — a Linkana extrai os dados da base, filtrados pelo cliente
Exportação — o arquivo CSV ou Parquet é depositado no bucket GCS do cliente
Consumo — o cliente acessa o bucket e integra os dados aos seus sistemas
Cada pipeline é executado automaticamente na recorrência acordada. A cada execução, a Linkana substitui o conteúdo da pasta de cada tabela pelo retrato completo do dia — não há carga incremental nem histórico, o que está no bucket é sempre o estado atual. Se precisar de histórico, copie os dados para o seu lado antes da execução seguinte.
Tabelas disponíveis
Atualmente, os pipelines cobrem as tabelas abaixo, que representam as principais dimensões da gestão de fornecedores:
Tabela | O que contém |
suppliers | Fornecedores cadastrados |
documents | Documentos dos fornecedores (formulários, bases públicas e consultas) |
form_fields | Respostas de perguntas de formulários |
buyer_documents | Campos personalizados preenchidos internamente associados ao fornecedor ou homologação |
setting_risks | Configurações de risco dos documentos por categoria |
qualifications | Homologações do fornecedor por categoria |
approval_steps | Níveis de aprovadores das etapas de aprovação |
performances | Respostas de avaliações de performance por ciclo |
cnpj_records | Dados cadastrais do CNPJ do fornecedor (base pública da Receita) |
tags | Marcadores aplicados ao fornecedor pelo comprador |
supplier_users | Usuários com conta na Linkana vinculados ao fornecedor |
O cliente contrata as tabelas de acordo com o caso de uso. Novas tabelas são comunicadas conforme forem disponibilizadas.
Formato e schema
Os arquivos são entregues em CSV ou Parquet, conforme a preferência do cliente definida na ativação. Nos arquivos CSV: encoding UTF-8, vírgula como delimitador, datas no padrão ISO 8601 e a primeira linha com os nomes dos campos.
Os dados refletem os valores originais do sistema — campos de estado, por exemplo, aparecem como clear, not_clear, in_progress. Não são aplicadas transformações de negócio customizadas, agregações ou cálculos derivados. O pipeline entrega os dados granulares da Linkana no nível mais detalhado disponível.
Cada tabela é exportada como uma pasta (exports/<tabela>/), não como um arquivo único. Leia a pasta inteira: tabelas maiores são fatiadas automaticamente em vários arquivos, e o nome de cada arquivo muda a cada execução. Todos os arquivos de uma pasta pertencem à mesma tabela e devem ser lidos em conjunto.
Os arquivos de uma mesma pasta podem ter colunas diferentes: quando uma coluna está vazia em todos os registros de um arquivo, ela não é escrita naquele arquivo. Por isso, una os arquivos pelo nome da coluna, nunca pela posição — unir por posição desalinha as colunas silenciosamente, sem erro. O dicionário de dados abaixo traz o conjunto completo de colunas de cada tabela; trate qualquer coluna ausente num arquivo como nula.
Leia os campos como texto primeiro e converta depois pelos tipos do dicionário. Campos como cnpj, cep e ddd1 têm zeros à esquerda que se perdem se a coluna for interpretada como número.
Dicionário de dados
Cada tabela tem um schema fixo. O dicionário abaixo descreve cada campo, seu tipo e os valores possíveis para campos enumerados.
Os tipos descritos são os da origem — no CSV, todo valor chega como texto, e a coluna Tipo indica como interpretá-lo. Todo campo datetime está em UTC, sem timezone explícito. Além das colunas listadas, cada tabela traz _dlt_load_id e _dlt_id (texto), identificadores técnicos da carga que podem ser descartados.
suppliers (Fornecedores cadastrados)
Campo | Tipo | Descrição |
| uuid | ID único do fornecedor |
| string | Razão Social |
| string | CNPJ, CPF ou TIN |
| string | Tipo de pessoa. Valores: |
| string | País do fornecedor |
| string | Estado do fornecedor no fluxo. Valores: |
| boolean | Se o fornecedor está sendo monitorado (conectado à base ativa do comprador) |
| boolean | Se o fornecedor está em processo de regularização interna pelo comprador |
| datetime | Data em que o fornecedor foi bloqueado (vazio se não bloqueado) |
| string | Nome do usuário que realizou o bloqueio |
| string | Motivo do bloqueio |
| datetime | Data de criação do registro |
| datetime | Data da última atualização do registro |
documents (Documentos dos fornecedores)
A tabela contém todo o histórico de documentos armazenados nos fornecedores cadastrados.
Campo | Tipo | Descrição |
| uuid | ID único do documento |
| uuid | ID do objeto associado (ver |
| string | Tipo do objeto associado. Valores: |
| date | Data de validade do documento |
| datetime | Data da próxima renovação |
| datetime | Data de revisão |
| string | E-mail do revisor |
| string | Comentário do revisor |
| string | Motivo da reprovação |
| string | E-mail de quem enviou o documento |
| datetime | Data de envio/geração |
| uuid | Referência às configurações do documento |
| string | Situação do documento. Valores: |
| uuid | ID do fornecedor |
| string | Nome de exibição do documento |
| string | Grupo de revisão |
| boolean | Indica se é a versão vigente do documento. Filtre por |
| datetime | Data de criação |
| datetime | Data de atualização |
form_fields (Respostas de perguntas de formulários)
Campo | Tipo | Descrição |
| uuid | ID único |
| string | Resposta da pergunta. Quando |
| uuid | Referência ao grupo de formulário. Para cruzar com |
| uuid | Referência à configuração da pergunta — chave estável para identificar a mesma pergunta entre exportações e fornecedores |
| string | Nome da pergunta |
| string | Tipo de resposta (ex.: |
| string | Dica para a resposta |
| boolean | Se a resposta é opcional |
| datetime | Data de criação |
| datetime | Data de atualização |
buyer_documents (Campos personalizados dos fornecedores)
Campos personalizados preenchidos internamente associados ao fornecedor ou homologação.
Campo | Tipo | Descrição |
| uuid | ID único do campo preenchido |
| uuid | ID do fornecedor |
| uuid | Referência à configuração do campo personalizado |
| string | Nome do campo |
| string | Valor preenchido |
| uuid | Homologação associada ao campo (vazio = campo associado diretamente ao fornecedor) |
| boolean | Se o campo está ativo |
| boolean | Se o campo foi arquivado |
| datetime | Data de criação |
| datetime | Data de atualização |
setting_risks (Configurações de risco do documento por categoria)
Campo | Tipo | Descrição |
| uuid | ID único |
| integer | Pontuação de risco do documento |
| uuid | Referência à categoria |
| uuid | Referência às configurações do documento |
| datetime | Data de criação |
| datetime | Data de atualização |
qualifications (Homologações do fornecedor por categoria)
Campo | Tipo | Descrição |
| uuid | ID único da homologação |
| datetime | Data da decisão |
| integer | Score de risco no momento da decisão |
| string | E-mail do usuário que iniciou a homologação |
| datetime | Data da próxima renovação da homologação |
| string | Situação da homologação. Valores: |
| uuid | Referência à categoria |
| string | Categoria |
| integer | Score de risco da categoria da homologação, do último cálculo consolidado (não é em tempo real). Sem risco configurado vem |
| uuid | ID do fornecedor |
| datetime | Data de criação |
| datetime | Data de atualização |
approval_steps (Níveis de aprovadores das etapas de aprovação)
Campo | Tipo | Descrição |
| uuid | ID único |
| string | E-mail do usuário aprovador |
| datetime | Data da decisão |
| string | Motivo padronizado (opcional para aprovação, obrigatório para reprovação) |
| string | Nome do nível de aprovação |
| string | Situação do nível. Valores: |
| datetime | Data da última decisão tomada na etapa |
| uuid | Referência à homologação |
| string | E-mail do usuário que acionou a etapa, se condição de aprovação por exceção |
| boolean | Se a etapa foi substituída por uma de aprovação por exceção |
| string | Situação da etapa. Valores: |
| string | Nome da etapa |
| datetime | Data de criação |
| datetime | Data de atualização |
performances (Respostas de avaliações de performance por ciclo)
Campo | Tipo | Descrição |
| uuid | ID único |
| string | Resposta da pergunta |
| string | Comentário textual do respondente junto com a resposta. Vem vazio (não |
| string | Critério. Valores: |
| string | Nome da pergunta |
| integer | Score calculado |
| boolean | Se a pergunta foi ignorada |
| integer | Peso da pergunta |
| string | Nome do pilar |
| integer | Score do pilar |
| integer | Peso do pilar |
| string | Nome da avaliação |
| datetime | Data em que a avaliação foi finalizada (vazio se ainda não finalizada) |
| string | Identificador único interno do cliente |
| integer | Score da avaliação |
| string | Situação da avaliação. Valores: |
| uuid | ID do fornecedor |
| string | E-mail do usuário que iniciou a avaliação |
| boolean | Se é o ciclo atual do cliente |
| string | Nome do ciclo |
| datetime | Data de criação |
| datetime | Data de atualização |
cnpj_records (Dados cadastrais do CNPJ)
Informações consultadas em dados públicos da Receita Federal. Fornecedores Pessoa Física ou internacionais não têm registro nesta tabela.
Campo | Tipo | Descrição |
| uuid | ID único do registro |
| uuid | ID do fornecedor |
| string | CNPJ do fornecedor (texto — preserva zeros à esquerda e acomoda o CNPJ alfanumérico; trate como string em qualquer cruzamento) |
| string | Razão social |
| string | Nome fantasia |
| string | Indicador matriz/filial (1 = matriz) |
| string | Código da situação cadastral |
| date | Data da situação cadastral |
| integer | Código do porte da empresa |
| integer | Código da natureza jurídica |
| string | CNAE fiscal principal |
| string | CNAEs secundários, separados por vírgula |
| date | Data de início de atividade |
| integer | Capital social em centavos (dividir por 100 para reais) |
| string | Regime tributário da empresa. Valores: |
| string | Tipo de logradouro (Rua, Avenida, etc.) |
| string | Logradouro |
| string | Número do endereço |
| string | Complemento do endereço |
| string | Bairro |
| string | Município |
| string | Unidade federativa |
| string | CEP |
| string | E-mail de contato |
| string | DDD do telefone principal |
| string | Telefone principal |
| datetime | Data de criação |
| datetime | Data de atualização |
tags (Marcadores do fornecedor)
Marcadores que o comprador aplica ao fornecedor para organização e segmentação da base.
Campo | Tipo | Descrição |
| uuid | ID único do marcador |
| uuid | ID do fornecedor |
| string | Nome do marcador |
| datetime | Data de criação |
| datetime | Data de atualização |
supplier_users (Usuários vinculados ao fornecedor)
Usuários com conta na Linkana que têm acesso a um fornecedor — diferente de contact_email (em suppliers), que é o contato declarado pelo fornecedor, não necessariamente alguém com login na plataforma. Só traz vínculos de usuários ativos: usuário removido da Linkana não aparece.
Campo | Tipo | Descrição |
| uuid | ID único do vínculo entre o usuário e o fornecedor |
| uuid | ID do fornecedor |
| string | E-mail do usuário vinculado ao fornecedor |
| datetime | Data em que o vínculo foi criado (não é a data de criação da conta do usuário) |
| datetime | Data da última atualização do vínculo (não da conta) |
Como cruzar as tabelas
As tabelas podem ser combinadas para responder perguntas de negócio mais completas. Alguns exemplos práticos:
Risco de um documento por categoria: cruzar
documentscomsetting_riskspelosetting_document_id. Ocategory_idemsetting_risksindica a qual categoria a pontuação se aplica.Resposta de um formulário e sua situação: cruzar
documentscomform_fieldsligandodocumentable_id(dedocuments) aform_group_id(deform_fields). Oanswertraz a resposta e ostatededocumentsa situação (ex.:clear= aprovado).Quem aprovou ou reprovou na homologação: usar
approval_steps—approver_user_email,decision_atedecision_reason— ligando à homologação porqualification_id.Desempenho de um fornecedor: agrupar
performancesporsupplier_id;evaluation_scoretraz o score consolidado epillar_scoreo score por pilar.Dados cadastrais e marcadores: cruzar
cnpj_recordsetagscomsupplierspelosupplier_id.Campos personalizados do comprador: cruzar
buyer_documentscomsupplierspelosupplier_id;display_nametraz o nome do campo evalueo valor preenchido.Usuários vinculados a um fornecedor: cruzar
supplier_userscomsupplierspelosupplier_id.
Links diretos para objetos na Linkana
Com os IDs dos dados exportados, é possível montar links diretos para os objetos na plataforma:
Objeto | URL | Campo utilizado |
Fornecedor |
|
|
Documento |
|
|
Campo personalizado |
|
|
Recorrência
A recorrência padrão de atualização é diária para todas as tabelas.
Acesso aos dados
Os dados são disponibilizados num bucket ou container dedicado por cliente, na cloud de sua preferência (Google Cloud Storage ou Azure Blob Storage). O acesso é sempre somente leitura e permanece sob controle do cliente.
Google Cloud Storage
O acesso é controlado via Service Account do Google Cloud com permissão apenas de leitura, em duas opções:
Opção preferencial: o cliente fornece uma Service Account própria e a Linkana concede permissão de leitura (storage.objectViewer) ao bucket. Recomendada porque o cliente mantém controle total sobre as credenciais e pode integrá-las diretamente aos seus pipelines.
Opção alternativa: caso o cliente não possua uma Service Account própria, a Linkana cria uma dedicada e compartilha a chave (JSON) de forma segura por link temporário. Em caso de rotação ou perda da chave, o cliente solicita uma nova via suporte.
Microsoft Azure — Blob Storage
Os dados ficam num container do Azure Blob Storage. Para conceder acesso de forma segura, o cliente cria uma identidade no Microsoft Entra ID autorizada a ler o container — mantendo controle total para rotacionar credenciais ou revogar o acesso a qualquer momento, sem depender da Linkana.
Pré-requisitos: conta Azure com permissão para criar App Registrations no Entra ID do tenant do cliente e acesso a portal.azure.com.
Passo a passo, do lado do cliente:
Criar uma App Registration — no portal Azure, abra Microsoft Entra ID → App registrations → New registration. Preencha: Name
linkana-data-access(ou outro de preferência); Supported account types = "Accounts in any organizational directory (Any Microsoft Entra ID tenant — Multitenant)" (sem isso a configuração não funciona); Redirect URI em branco. Clique em Register.Coletar IDs — na aba Overview da App Registration, copie o Application (client) ID e o Directory (tenant) ID.
Gerar um Client Secret — em Certificates & secrets → New client secret, gere o segredo e guarde o valor com segurança.
Enviar para a Linkana — envie apenas o Application (client) ID e o Tenant ID. Não envie o Client Secret: ele fica somente com o cliente. A Linkana nunca precisa do segredo, só dos dois identificadores.
Do lado da Linkana: fazemos o admin consent do app no nosso tenant (provisiona uma referência da identidade do cliente no nosso diretório) e atribuímos a role Storage Blob Data Reader sobre o container, concedendo acesso somente leitura.
Atenção: se vocês usam outro provedor de cloud, entrem em contato com o gestor de conta da Linkana para análise de viabilidade técnica.
Estrutura das pastas no bucket
gs://{bucket}/lk-{cliente}/exports/
suppliers/
documents/
form_fields/
buyer_documents/
setting_risks/
qualifications/
approval_steps/
performances/
cnpj_records/
tags/
supplier_users/
A mesma estrutura de pastas se aplica ao container do Azure Blob Storage. As pastas com prefixo _dlt (como _dlt_loads, _dlt_pipeline_state, _dlt_version) são de controle interno do pipeline de exportação e podem ser ignoradas na integração.
Processo de ativação
A ativação é imediata: todas as tabelas são disponibilizadas assim que o cliente responder:
Qual o provedor de cloud? (Google Cloud ou Microsoft Azure)
Se for Google Cloud, o cliente fornece a Service Account ou precisa que a Linkana crie uma?
Prefere receber os dados em CSV ou Parquet?
Com essas respostas e o acesso configurado (conforme a seção "Acesso aos dados"), o pipeline entra em operação.
Alterações de schema e SLA
A Linkana comunica alterações no schema com no mínimo 30 dias de antecedência, garantindo tempo hábil para que o time de dados ajuste suas integrações antes da aplicação.
Em caso de falha na exportação, o time da Linkana é notificado automaticamente. O pipeline é reprocessado e o cliente é informado sobre eventuais atrasos.
Perguntas frequentes
Os dados são incrementais ou full load?
Sempre full load. Cada exportação contém todos os registros válidos no momento da extração.
Posso pedir campos customizados?
Em geral, não. O schema de cada pipeline segue os campos padrão disponíveis na Linkana. Se um campo novo for adicionado à plataforma e for relevante para o seu caso de uso, ele pode ser incluído no pipeline mediante alinhamento prévio.
Posso usar com BigQuery, Databricks, Power BI ou ferramentas do Azure?
Sim. O bucket (Google Cloud Storage) ou o container (Azure Blob Storage) é acessível por qualquer ferramenta que suporte leitura desses storages. No Google Cloud, o BigQuery cria tabelas externas diretamente sobre os arquivos; no Azure, ferramentas como Synapse, Databricks e Power BI leem o container diretamente.
Como sei se o pipeline foi executado com sucesso?
A presença do arquivo atualizado no bucket indica que a execução foi bem-sucedida — a data de atualização do arquivo muda a cada rodada. Em caso de falha, o time da Linkana é notificado automaticamente e comunica o cliente sobre o status.
Uma tabela ou pasta está vazia ou não apareceu. É falha na integração ou ela não existe para o meu caso?
Na maioria dos casos, é ausência legítima — não falha. O pipeline é monitorado internamente pela nossa ferramenta de orquestração: quando uma exportação falha, o time da Linkana é notificado automaticamente e faz a correção, sem depender de você perceber.
Para confirmar do seu lado, verifique a data de atualização do arquivo: ela muda a cada execução bem-sucedida (o pipeline roda diariamente). Se a data mudou, o pipeline rodou.
Algumas tabelas dependem de recursos que o comprador pode não usar e, nesses casos, vêm vazias — sem que isso seja erro. Por exemplo: se você não usa o módulo de performance, a tabela performances vem vazia; o mesmo vale para tags se você não aplica marcadores. A forma mais simples de tirar a dúvida é entrar na Linkana e verificar se aquele dado existe na aplicação ou nos dashboards: se não existe lá, não existe no export.
Com quem eu falo sobre problemas no pipeline?
Pelo canal de suporte habitual da Linkana (e-mail ou plataforma), referenciando o nome do pipeline e a data do arquivo.
