Fibery

Usuários, databases, campos e entidades de um workspace Fibery no Data Catalog e no Memory, e o texto das Document Views e dos campos rich text no Knowledge, com a permissão de cada database.

O conector Fibery lê os usuários, os databases, os campos e as entidades de um workspace Fibery, e o texto das Document Views e dos campos rich text das entidades. Com cada item, ele grava quem pode lê-lo segundo as permissões de cada database no Fibery.

Status	Disponível
Conteúdo	Registros e documentos
Autenticação	Chave de API do usuário
Permissões	Por item
Sincronização	Full refresh
Última revisão	23/10/2026

Capacidades

• Traz ao Data Catalog os usuários do workspace, os databases que o cliente criou (Task, Project, Meeting ou qualquer outro), os campos de cada database, as entidades de todos os databases e os valores dos campos personalizados, um valor por linha.
• Publica seis modelos limpos: fibery_users, fibery_databases, fibery_fields, fibery_entities, fibery_entity_assignees e fibery_entity_field_values, com datas em UTC e e-mails em minúsculas.
• Alimenta o Memory pelo fragmento de ontologia do conector. As pessoas viram nós Agent e as entidades viram nós WorkItem, ligados por “atribuída a” e “criada por”, e a criação de cada entidade entra na linha do tempo. As pessoas se unem às de outras fontes pelo e-mail. Os nós só entram no grafo depois que a ontologia unificada é aplicada.
• Envia ao Knowledge cada Document View não privada e cada campo rich text preenchido de cada entidade, como um documento em Markdown com o link para o Fibery.
• Calcula a permissão de cada registro e de cada documento de entidade a partir de quem lê o database no Fibery (ver Permissões).

Recursos disponíveis

Recurso	O que contém	Carga	Cursor	Destino	Permissão por item
users	Usuários do workspace, com name, email, role, is_admin, is_guest, is_active e kind	Full refresh	Nenhum	Catálogo e Memory	Sim
databases	Databases que o cliente criou, com name (Space/Database), space, mixins e o campo que serve de título	Full refresh	Nenhum	Catálogo	Sim
fields	Campos de cada database, inclusive os de sistema, com type, is_collection, is_rich_text e is_read_only	Full refresh	Nenhum	Catálogo	Sim
entities	Uma linha por entidade de cada database (uma task, um projeto, uma reunião), com title, state, assignee_ids, created_by_id, datas e url	Full refresh	Nenhum	Catálogo e Memory	Sim
entity_field_values	Um valor de campo personalizado por linha, com o nome e o tipo do campo, value_text e value_ref_id	Full refresh	Nenhum	Catálogo	Sim
documents	Texto em Markdown de cada Document View não privada, sem as imagens	Full refresh	Nenhum	Knowledge	Não
entity_documents	Texto em Markdown de cada campo rich text preenchido de cada entidade, sem as imagens	Full refresh	Nenhum	Knowledge	Sim

Os databases e os campos são os que o cliente criou no Fibery, então eles chegam como linhas desses recursos, e os sete recursos são os mesmos em qualquer workspace. Os dados de uma task, por exemplo, estão numa linha de entities e nas linhas de entity_field_values dessa entidade.

No Data Catalog, documents e entity_documents nascem ligados, users fica sempre ligado e os demais recursos nascem desligados. Você escolhe quais carregar depois de conectar. As tabelas clean também nascem desligadas.

users não pode ser desligado porque é por ele que a Strattum descobre o e-mail de quem lê cada database. Sem ele, nenhum registro nem documento ficaria visível no modo “Espelhar a fonte”.

O conector lê todo database que o usuário da chave lê. Não há seleção de databases ou de spaces.

Um campo rich text vira um documento por entidade, e uma entidade com dois campos rich text gera dois documentos. O título é <título da entidade> · <nome do campo>. Uma entidade sem título usa o nome do database e o public id dela. Uma Document View usa o próprio nome. Um texto vazio não vira documento, e um texto acima de 1.000.000 de caracteres é cortado nesse limite.

Como ler os dados

• entity_key (database_id:external_id) é a chave única de fibery_entities, e fibery_entity_assignees e fibery_entity_field_values a carregam. O id da entidade sozinho não serve de chave, porque o Fibery não documenta que ele é único entre databases.
• database_name diz de que database a entidade vem, no formato Space/Database (por exemplo, Project Tracking/Task). A mesma tabela traz tasks, projetos e reuniões.
• title é o campo marcado como título no database, NULL quando o database não tem título. state é o nome do estado do workflow, NULL em database sem workflow.
• assignee_ids traz até 100 responsáveis. assignees_truncated fica true quando a entidade tinha mais, e então a lista traz só os 100 primeiros. Há uma linha por responsável em fibery_entity_assignees.
• created_by_id e user_external_id apontam para fibery_users.external_id. fibery_users só tem pessoas: o usuário de integração do próprio workspace (kind/service) fica só na raw, então uma entidade criada por ele aponta para um id que a tabela não tem.
• Em fibery_entity_field_values, ordinal é 0 num campo com um valor e a posição do item numa coleção. value_text é o valor em texto: número, data ISO, true ou false, o nome da opção escolhida, o título da entidade ligada ou o nome do usuário. Um intervalo de datas chega como o JSON que o Fibery envia. value_ref_id é o id do alvo de uma relação, de uma seleção ou de um usuário.
• Numa relação com outro database, field_type é o nome do database de destino e value_ref_id é o external_id da entidade ligada. value_text fica NULL quando nem todo leitor do database da entidade lê o database de destino (ver Permissões).
• truncated marca as linhas de uma coleção que passou de 100 itens. As linhas são os 100 primeiros itens.
• created_at e source_updated_at estão em UTC. source_updated_at é a data de modificação informada pelo Fibery.
• url é o link da entidade no workspace, NULL quando ela não tem public id.
• fibery_users.email está em minúsculas, e fica NULL quando o endereço é vazio. phone é sempre NULL, porque a API não o informa.

Permissões (ACL)

O conector lê a permissão de cada item na fonte e a guarda junto com o dado. Em Comportamento dos dados, você escolhe entre dois modos:

Modo	Quem vê
Aberto	Quem puder usar este conector vê todos os registros. As permissões da fonte são ignoradas.
Espelhar a fonte	Cada pessoa vê apenas os registros que a própria fonte libera para ela.

No modo “Espelhar a fonte”, a Strattum reconhece cada pessoa pelo e-mail que ela tem no Fibery. O conector grava esse e-mail como uma identidade do Fibery, ligada a esta conexão, e assume que a pessoa usa o mesmo e-mail na Strattum. O Fibery não tem a opção Exigir login na fonte como prova de identidade.

No passo de acesso do assistente de criação, o Comportamento dos dados começa em “Aberto”.

Como a fonte define acesso

No Fibery, o acesso é dado por space. Um space pode ser aberto a todos os membros ou a grupos de usuários, em níveis como Viewer, Editor e Creator, ou ficar fechado. Também é possível compartilhar uma entidade ou um documento com uma pessoa específica. A API informa, para cada database, quem lê as entidades dele e de onde vem esse acesso. Ela não informa quem lê uma Document View nem com quem uma entidade foi compartilhada.

Como a Strattum traduz o acesso

Em cada execução, antes de ler qualquer entidade, o conector consulta quem lê cada database. Uma pessoa lê o database quando alguma das origens de acesso dela inclui a leitura de entidades (entity.read). Os admins do workspace aparecem como leitores mesmo de um space fechado aos membros.

Item	Quem recebe acesso
entities, entity_field_values, databases, fields	Quem lê o database
entity_documents	Quem lê o database da entidade
users	Todos os usuários ativos do workspace com e-mail, exceto o usuário de integração
documents	Ninguém. O Fibery não informa quem lê uma Document View

Cada pessoa vira uma identidade do Fibery pelo e-mail, ligada a esta conexão. A consulta de acesso devolve um id interno de cada pessoa, e o e-mail vem da lista de usuários lida na mesma execução.

O título de uma entidade de outro database é conteúdo desse outro database. Em entity_field_values, ele só é gravado quando todos os leitores do database da entidade também leem o database de destino. Nos outros casos, a linha guarda só o id da entidade ligada (value_ref_id).

As Document Views ficam fora da busca no modo “Espelhar a fonte”, porque não têm leitores conhecidos. No modo “Aberto”, elas entram no Knowledge e ficam visíveis para todo mundo que pode usar o conector. Uma Document View privada, do “My space”, nunca é lida.

Quando a identidade não é encontrada

Quando o conector não consegue confirmar quem lê um item, o item fica com menos leitores ou com nenhum.

• Um usuário sem e-mail, um usuário inativo e o usuário de integração do workspace (kind/service) não recebem acesso.
• Um leitor cujo id não corresponde a nenhum usuário lido na execução fica de fora.
• Quem só recebeu uma entidade compartilhada, sem acesso ao database dela, não vê a entidade na Strattum.
• Um database cuja leitura o Fibery recusa ao usuário da chave (resposta 403) não é lido nem gravado, e as linhas que ele tinha saem das tabelas. O resumo da execução diz quantos databases ficaram de fora.
• Se nenhum database pode ser lido, a execução falha inteira e nada é gravado, nem users.
• Qualquer outra falha na consulta de acesso faz a execução falhar antes de gravar, e as tabelas ficam como estavam.
• Um registro sem nenhum leitor fica invisível no modo “Espelhar a fonte”. Um documento de entidade nessa situação não é entregue ao Knowledge. Se já estava indexado, o conteúdo continua lá, mas sem leitores.
• Quem usa na Strattum um e-mail diferente do que usa no Fibery não vê nada no modo “Espelhar a fonte”.

Quando a permissão é atualizada

Toda execução consulta de novo quem lê cada database e regrava todos os registros e documentos de entidade com a permissão atual. Uma mudança de acesso no Fibery vale na Strattum na execução seguinte, em até 6 horas com a frequência recomendada.

Pré-requisitos

• Um workspace do Fibery e o endereço dele (acme, em acme.fibery.io).
• A chave de API de um usuário que lê os spaces que devem entrar na Strattum. O conector só alcança o que esse usuário alcança. Prefira um usuário dedicado à integração, com acesso só a esses spaces.
• Esse usuário precisa conseguir consultar quem tem acesso aos databases. O teste de conexão confere essa consulta e bloqueia o cadastro se ela falhar.
• Uma só conexão Fibery por instalação da Strattum.

Autenticação e escopos

A autenticação usa uma chave de API do Fibery, enviada no cabeçalho Authorization: Token <chave> só para o endereço do workspace. A chave não tem escopos: ela tem os mesmos privilégios do usuário que a criou. Cada usuário pode ter até 3 chaves.

Permissão do usuário	Para quê
Leitura dos spaces e databases que serão sincronizados	Ler a estrutura do workspace, as entidades, os campos rich text e as Document Views. O que o usuário não lê não chega à Strattum
Leitura dos usuários do workspace	Gravar users e descobrir o e-mail de quem lê cada database
Consulta de quem tem acesso a cada database (fibery.type/query-capability-sources)	Calcular quem vê cada item. O teste de conexão confere essa consulta

1. Entre com o usuário do conector

   Acesse o Fibery com o usuário cuja chave o conector vai usar.

2. Abra as chaves de API

   No menu do workspace, abra Settings e, na seção API, clique em API Keys.

3. Gere e copie a chave

   Clique em Generate API key e copie a chave gerada.

4. Anote o workspace

   O workspace é o início do endereço em que você abre o Fibery: em acme.fibery.io, é acme.

A chave tem os mesmos privilégios do usuário no Fibery, inclusive os de edição que ele tiver. O conector só envia comandos de leitura, mas guarde a chave em local seguro e nunca a publique em repositórios.

Configuração no Console

1. Abra o assistente

   Em Conectores, crie uma nova conexão e selecione Fibery.

2. Preencha a conexão

   Nome do Conector (Opcional): como a conexão aparece na lista. O padrão é Fibery.

   Workspace (Obrigatório): o subdomínio do workspace, acme em acme.fibery.io. Colar o endereço completo também funciona.

   API Token (Obrigatório): a chave gerada em API Keys.

3. Teste a conexão

   Clique em Testar Conexão. Você só avança depois de um teste com sucesso. O teste lê a estrutura do workspace e um usuário, e consulta quem tem acesso a até 5 databases. Um database que recusa a consulta é pulado, e basta um responder para o teste passar. Se todos os consultados recusarem, o teste falha.

4. Escolha a frequência

   Em Frequência de Sincronização (Obrigatório), escolha a frequência. A opção recomendada é “A cada 6h”.

5. Defina o acesso

   Em Permissionamento, defina Quem pode usar este conector (Obrigatório) e o Comportamento dos dados (Obrigatório). O padrão é “Todos os usuários” e “Aberto”.

6. Revise e salve

   Em Revisão, confira os dados e salve. Depois, no Data Catalog, ligue os recursos e as tabelas clean que você quer carregar e marque os dados pessoais, se houver. Ver Dados pessoais (PII).

O workspace não muda depois da criação. Na edição do conector, ele aparece só para leitura, e você pode trocar o nome, a chave, a frequência e o acesso.

Os documentos do Fibery só aparecem na busca quando um contexto do Knowledge inclui o conector. O contexto recebe todos os documentos do Fibery, sem recorte por space ou por database.

Como a sincronização funciona

A frequência vem do passo Frequência de Sincronização. A referência do conector é uma execução a cada 6 horas, em UTC. Além dela, roda uma verificação completa por dia, às 03:00 por padrão.

Ordem. Em cada execução, o conector lê a estrutura do workspace e os usuários, e depois consulta quem lê cada database. Em seguida grava users, lê cada database uma vez para montar entities, entity_field_values e entity_documents, depois monta databases e fields, e por último lê as Document Views. Recurso desligado no Data Catalog não é gravado, e os databases só são varridos quando entities, entity_field_values ou entity_documents está ligado.

Paginação. As entidades de cada database são lidas em páginas de 1.000, em ordem de id. Um database que passe de 10.000 páginas faz o recurso falhar. Coleções (responsáveis, seleções múltiplas, relações com muitas entidades) vêm junto com a entidade, até 100 itens. Os textos são pedidos em lotes de 50, e a lista de views vem numa só chamada.

Full refresh. Todos os recursos são lidos por inteiro em toda execução, inclusive o texto de todos os documentos, porque o Fibery não dá um sinal de mudança confiável. Cada recurso de registros é lido inteiro antes de ser gravado, e a tabela dele é substituída. O Knowledge só reindexa o documento cujo texto mudou.

Remoção. Uma entidade, um campo ou um database apagado no Fibery some das tabelas na execução seguinte. No Knowledge, um documento apagado, ou um texto que ficou vazio, só sai numa verificação completa: a diária ou uma Sincronização completa pedida no contexto. A remoção só acontece quando a leitura inteira deu certo e documents e entity_documents estão ligados. Ver Atualização e remoção de documentos.

Falhas. Se a leitura de um recurso falhar, a tabela dele fica como estava na última execução boa e o resumo da execução nomeia o recurso. Uma falha ao ler os textos das entidades afeta só entity_documents, e os registros seguem. Um documento sem link ou sem texto nesta execução fica com a versão anterior no Knowledge, se houver.

Avisos. Coleções cortadas em 100 itens e Document Views fora da busca no modo “Espelhar a fonte” aparecem no resumo da execução como informação. Databases fora do alcance do usuário da chave e documentos com falha aparecem como aviso.

API da fonte

Todas as chamadas são POST no endereço do workspace, https://<workspace>.fibery.io.

Método e caminho	Usado para	Recurso
POST /api/commands com fibery.schema/query	Ler a estrutura do workspace (databases e campos); teste de conexão	databases, fields
POST /api/commands com fibery.entity/query em fibery/user	Listar os usuários	users, Permissão
POST /api/commands com fibery.entity/query em cada database	Ler as entidades, página por página	entities, entity_field_values, entity_documents
POST /api/commands com fibery.entity/query em fibery/app	Ler o nome dos spaces, para montar o link das Document Views	documents
POST /api/commands com fibery.type/query-capability-sources	Consultar quem lê cada database; teste de conexão	Permissão
POST /api/views/json-rpc com query-views	Listar as views do workspace	documents
POST /api/documents/commands?format=md com get-documents	Ler o texto em Markdown, até 50 por chamada	documents, entity_documents

Rate limits. O Fibery aceita 3 requisições por segundo por chave e 7 por segundo no workspace inteiro, e responde 429 acima disso. O limite do workspace é dividido com as pessoas e as outras integrações que usam o Fibery. O conector envia uma requisição por vez, no máximo 2 por segundo. Diante de um 429, ele espera o maior entre o tempo do cabeçalho Retry-After, que o Fibery envia, e um recuo que começa em 2 segundos e dobra até 60, e tenta de novo, até 8 tentativas no total. Erros 5xx seguem o mesmo recuo e o mesmo número de tentativas. Uma conexão que cai antes da resposta é repetida até 2 vezes, depois de 2 e de 4 segundos. Cada requisição espera no máximo 60 segundos. Esgotadas as tentativas, se a chamada era da estrutura, dos usuários ou da consulta de acesso, a execução inteira falha. Nos outros casos, só o recurso em leitura falha.

Referência oficial: Fibery, Request limits

Limitações conhecidas

• Não há carga incremental. Toda execução relê o workspace inteiro, inclusive o texto de todos os documentos, a no máximo 2 requisições por segundo.
• A permissão é por database. Compartilhar uma entidade ou um documento com uma pessoa no Fibery não dá acesso a ele na Strattum.
• As Document Views ficam fora da busca no modo “Espelhar a fonte”. No modo “Aberto”, ficam visíveis para todo mundo que pode usar o conector.
• A Strattum verificou a consulta de acesso aos databases só com a chave de um admin do workspace. Com a chave de um usuário que não é admin, a consulta não foi testada. O teste de conexão bloqueia o cadastro se ela falhar.
• Não dá para escolher databases ou spaces. O conector lê tudo o que o usuário da chave lê, e para deixar um database de fora é preciso tirar o acesso desse usuário no Fibery. No Knowledge, o contexto recebe todos os documentos do Fibery, sem recorte por space.
• Comentários e arquivos anexados às entidades não são lidos.
• Coleções com mais de 100 itens guardam só os 100 primeiros, marcados com truncated (ou assignees_truncated, nos responsáveis).
• Campos de tipos cujo formato não foi verificado, como localização, JSON e cor, não são gravados.
• Os campos personalizados chegam em formato longo, um valor por linha, sem uma tabela com colunas próprias para cada database. No Memory, eles não viram propriedades nem ligações entre entidades.
• Uma entidade sem public id não tem link, e os campos rich text dela não são publicados no Knowledge. O mesmo vale para uma Document View sem public id ou cujo space não tem nome.
• Textos acima de 1.000.000 de caracteres são cortados nesse limite. Imagens coladas no texto são removidas.
• O conector não mascara dados pessoais dentro do texto dos documentos. email de users e value_text de entity_field_values são sugeridos para mascaramento no painel de dados pessoais do Data Catalog. Nada é mascarado até você aplicar a sugestão e salvar. O title de entities não tem sugestão, porque é o nome de exibição da entidade no grafo; se ele puder trazer dado pessoal no seu workspace, marque-o no mesmo painel.
• Um e-mail ou CPF mascarado em value_text vira um marcador e não se une ao mesmo dado em outros conectores.
• O Fibery não permite vincular a conta de cada usuário: a identidade é o e-mail do usuário no Fibery.
• O workspace não muda depois da criação, e cada instalação tem uma só conexão Fibery. Para ler outro workspace, é preciso remover a conexão atual antes de criar a nova.
• Um item apagado no Fibery sai das tabelas na execução seguinte, mas o documento dele só sai do Knowledge na verificação completa.

Troubleshooting

Mensagem ou sintoma	Causa	O que fazer
O workspace do Fibery é obrigatório.	O campo Workspace está vazio.	Informe o subdomínio: acme em acme.fibery.io.
O workspace informado não é um endereço do Fibery.	O valor não é um subdomínio de fibery.io, ou tem porta ou senha.	Use o subdomínio (acme) ou o endereço do workspace, https://acme.fibery.io.
O token da API do Fibery é obrigatório.	O campo API Token está vazio.	Gere uma chave em Settings > API > API Keys e cole-a no campo.
Não foi possível contatar o workspace do Fibery.	O workspace não existe, o endereço está errado ou há falha de rede.	Confira o endereço e a conectividade de rede e tente de novo.
Token da API do Fibery inválido.	A chave está errada, foi apagada ou é de outro workspace.	Gere uma nova chave no workspace informado e cole-a no campo.
Não foi possível ler a estrutura do workspace (HTTP <status>).	O Fibery recusou a leitura da estrutura.	Tente de novo. Se persistir, confira se o dono da chave consegue abrir o workspace.
Não foi possível ler os usuários do workspace (HTTP <status>).	O Fibery recusou a leitura dos usuários.	Tente de novo. Se persistir, confira o acesso do dono da chave.
O token não consegue ler quem tem acesso aos databases.	O dono da chave não tem o privilégio de consultar permissões, ou não lê nenhum dos databases consultados. O Fibery não distingue os dois casos.	Dê a esse usuário o privilégio e acesso aos spaces que devem ser sincronizados, ou gere a chave com um usuário que tenha os dois.
Não foi possível verificar a leitura das permissões dos databases.	O Fibery não respondeu à consulta, por limite de requisições ou instabilidade.	Aguarde alguns segundos e teste de novo.
A leitura das permissões dos databases teve uma resposta inesperada (HTTP <status>).	O Fibery respondeu de um jeito que o conector não reconhece.	Teste de novo. Se persistir, informe o status HTTP ao suporte.
O usuário dono do token não lê nenhum dos <count> databases do workspace.	Na sincronização, todos os databases recusaram a leitura. Nada foi gravado.	Dê ao usuário acesso aos spaces e o privilégio de consultar permissões, ou use a chave de um usuário que tenha os dois, e sincronize de novo.
O workspace do Fibery não muda depois da criação.	A edição tentou trocar o workspace.	Remova a conexão atual e crie uma nova para o outro workspace.
O resumo da execução diz que o usuário do token não lê algumas databases.	O Fibery respondeu 403 para esses databases.	Dê ao usuário da chave acesso aos spaces deles, se devem entrar na Strattum.
Documentos do Fibery não aparecem na busca.	Nenhum contexto do Knowledge inclui o conector.	Inclua o conector Fibery num contexto do Knowledge.
As Document Views não aparecem na busca.	O conector está no modo “Espelhar a fonte”.	Use o modo “Aberto” se as views podem ser vistas por todos que usam o conector.
Uma pessoa não vê nada no modo “Espelhar a fonte”.	O e-mail dela na Strattum é diferente do e-mail no Fibery, ou ela só tem acesso por uma entidade compartilhada.	Use o mesmo e-mail nos dois, ou dê a ela acesso ao space no Fibery.

Próximos passos

Data Catalog

Ligue os recursos e as tabelas clean do Fibery e marque os dados pessoais.

Knowledge

Veja como as Document Views e os textos das entidades do Fibery são indexados e buscados.

Desenvolvimento local

O conector não lê credenciais de variáveis de ambiente. O workspace e a chave são gravados por conexão, quando você cria a conexão no Console, com as chaves FIBERY_ACCOUNT e FIBERY_API_TOKEN. Para testar localmente, suba o ambiente pelo guia de desenvolvimento local e crie a conexão pelo Console desse ambiente.