defineLogicFunction
Defina funções de lógica e seus gatilhos
defineLogicFunction
Defina funções de lógica e seus gatilhos
Cada arquivo de função usa Tipos de gatilho disponíveis:O tipo
No seu manipulador, acesse os cabeçalhos encaminhados assim:Pontos-chave:
defineLogicFunction() para exportar uma configuração com um manipulador e gatilhos opcionais.src/logic-functions/createPostCard.logic-function.ts
- httpRoute: Expõe sua função em um caminho e método HTTP no endpoint
/s/:
por exemplo,path: '/post-card/create'é acessível emhttps://your-twenty-server.com/s/post-card/create
- cron: Executa sua função em um agendamento usando uma expressão CRON.
- databaseEvent: Executa em eventos do ciclo de vida de objetos do espaço de trabalho. Quando a operação do evento é
updated, campos específicos a serem observados podem ser especificados no arrayupdatedFields. Se deixar indefinido ou vazio, qualquer atualização acionará a função.
por exemplo,person.updated,*.created,company.*
Você também pode executar manualmente uma função usando a CLI:Você pode acompanhar os logs com:
Payload de gatilho de rota
Quando um gatilho de rota invoca sua função de lógica, ela recebe um objetoRoutePayload que segue o formato HTTP API v2 da AWS.
Importe o tipo RoutePayload de twenty-sdk:RoutePayload tem a seguinte estrutura:| Propriedade | Tipo | Descrição | Exemplo |
|---|---|---|---|
headers | Record\<string, string | undefined> | Cabeçalhos HTTP (apenas aqueles listados em forwardedRequestHeaders) | veja a seção abaixo |
queryStringParameters | Record\<string, string | undefined> | Parâmetros de query string (valores múltiplos unidos por vírgulas) | /users?ids=1&ids=2&ids=3&name=Alice -> { ids: '1,2,3', name: 'Alice' } |
pathParameters | Record\<string, string | undefined> | Parâmetros de caminho extraídos do padrão de rota | /users/:id, /users/123 -> { id: '123' } |
body | object | null | Corpo da requisição analisado (JSON) | { id: 1 } -> { id: 1 } |
isBase64Encoded | boolean | Se o corpo está codificado em base64 | |
requestContext.http.method | string | Método HTTP (GET, POST, PUT, PATCH, DELETE) | |
requestContext.http.path | string | Caminho bruto da requisição |
forwardedRequestHeaders
Por padrão, os cabeçalhos HTTP das requisições recebidas não são repassados para sua função de lógica por motivos de segurança. Para acessar cabeçalhos específicos, liste-os explicitamente no arrayforwardedRequestHeaders:Os nomes dos cabeçalhos são normalizados para minúsculas. Acesse-os usando chaves em minúsculas (por exemplo,
event.headers['content-type']).Expor uma função como ferramenta
Funções lógicas podem ser expostas como ferramentas para agentes de IA e fluxos de trabalho. Quando marcada como ferramenta, uma função fica detectável pelos recursos de IA do Twenty e pode ser usada em automações de fluxos de trabalho.Para marcar uma função de lógica como ferramenta, definaisTool: true:src/logic-functions/enrich-company.logic-function.ts
- Você pode combinar
isToolcom gatilhos — uma função pode ser ao mesmo tempo uma ferramenta (chamável por agentes de IA) e acionada por eventos. toolInputSchema(opcional): Um objeto JSON Schema que descreve os parâmetros que sua função aceita. O schema é calculado automaticamente a partir da análise estática do código-fonte, mas você pode defini-lo explicitamente:
Escreva uma boa
description. Os agentes de IA dependem do campo description da função para decidir quando usar a ferramenta. Seja específico sobre o que a ferramenta faz e quando ela deve ser chamada.definePostInstallLogicFunction
Defina uma função de lógica de pós-instalação (uma por aplicativo)
definePostInstallLogicFunction
Defina uma função de lógica de pós-instalação (uma por aplicativo)
Uma função de pós-instalação é uma função lógica que é executada automaticamente assim que seu aplicativo terminar de ser instalado em um espaço de trabalho. O servidor a executa depois que os metadados do aplicativo forem sincronizados e o cliente do SDK for gerado, para que o espaço de trabalho esteja totalmente pronto para uso e o novo esquema esteja disponível. Casos de uso típicos incluem popular dados padrão, criar registros iniciais, configurar as definições do espaço de trabalho ou provisionar recursos em serviços de terceiros.Você também pode executar manualmente a função de pós-instalação a qualquer momento usando a CLI:Pontos-chave:
src/logic-functions/post-install.ts
- As funções de pós-instalação usam
definePostInstallLogicFunction()— uma variante especializada que omite as configurações de gatilho (cronTriggerSettings,databaseEventTriggerSettings,httpRouteTriggerSettings,isTool). - O manipulador recebe um
InstallPayloadcom{ previousVersion?: string; newVersion: string }—newVersioné a versão que está sendo instalada, epreviousVersioné a versão que foi instalada anteriormente (ouundefinedem uma instalação nova). Use esses valores para distinguir instalações novas de atualizações e para executar lógica de migração específica da versão. - Quando o hook é executado: apenas em instalações novas, por padrão. Passe
shouldRunOnVersionUpgrade: truese você também quiser que ele seja executado quando o app for atualizado a partir de uma versão anterior. Quando omitida, a flag tem valor padrãofalsee as atualizações ignoram o hook. - Modelo de execução — assíncrono por padrão, síncrono opcional: a flag
shouldRunSynchronouslycontrola como a pós-instalação é executada.shouldRunSynchronously: false(padrão) — o hook é enfileirado na fila de mensagens comretryLimit: 3e é executado de forma assíncrona em um worker. A resposta da instalação retorna assim que o job é enfileirado, então um manipulador lento ou com falha não bloqueia quem chamou. O worker tentará novamente até três vezes. Use isto para jobs de longa duração — popular grandes conjuntos de dados, chamar APIs de terceiros lentas, provisionar recursos externos, qualquer coisa que possa exceder uma janela razoável de resposta HTTP.shouldRunSynchronously: true— o hook é executado inline durante o fluxo de instalação (mesmo executor da pré-instalação). A requisição de instalação bloqueia até o manipulador terminar e, se ele lançar uma exceção, quem chamou a instalação recebe umPOST_INSTALL_ERROR. Sem novas tentativas automáticas. Use isto para trabalhos rápidos que precisam ser concluídos antes da resposta — por exemplo, emitir um erro de validação para o usuário ou fazer uma configuração rápida da qual o cliente dependerá imediatamente após a chamada de instalação retornar. Tenha em mente que a migração de metadados já foi aplicada quando a pós-instalação é executada, então uma falha no modo síncrono não reverte as alterações de esquema — ela apenas expõe o erro.
- Garanta que seu manipulador seja idempotente. No modo assíncrono, a fila pode tentar novamente até três vezes; em qualquer modo, o hook pode ser executado novamente em atualizações quando
shouldRunOnVersionUpgrade: true. - As variáveis de ambiente
APPLICATION_ID,APP_ACCESS_TOKENeAPI_URLestão disponíveis dentro do manipulador (assim como em qualquer outra função de lógica), então você pode chamar a API da Twenty com um token de acesso de aplicativo com escopo para o seu app. - É permitida apenas uma função de pós-instalação por app. A geração do manifesto apresentará erro se mais de uma for detectada.
- O
universalIdentifier,shouldRunOnVersionUpgradeeshouldRunSynchronouslyda função são anexados automaticamente ao manifesto do aplicativo no campopostInstallLogicFunctiondurante o build — você não precisa referenciá-los emdefineApplication(). - O tempo limite padrão é definido como 300 segundos (5 minutos) para permitir tarefas de configuração mais longas, como o pré-carregamento de dados.
- Não executado no modo de desenvolvimento: quando um app é registrado localmente (via
yarn twenty dev), o servidor pula completamente o fluxo de instalação e sincroniza arquivos diretamente pelo watcher da CLI — portanto, a pós-instalação nunca é executada no modo de desenvolvimento, independentemente deshouldRunSynchronously. Useyarn twenty exec --postInstallpara acioná-lo manualmente em um workspace em execução.
definePreInstallLogicFunction
Defina uma função de lógica de pré-instalação (uma por aplicativo)
definePreInstallLogicFunction
Defina uma função de lógica de pré-instalação (uma por aplicativo)
Uma função de pré-instalação é uma função de lógica que é executada automaticamente durante a instalação, antes que a migração de metadados do workspace seja aplicada. Ela compartilha o mesmo formato de payload que a pós-instalação (Você também pode executar manualmente a função de pré-instalação a qualquer momento usando a CLI:Pontos-chave:
InstallPayload), mas está posicionada mais cedo no fluxo de instalação para poder preparar o estado do qual a próxima migração depende — usos típicos incluem fazer backup de dados, validar a compatibilidade com o novo esquema ou arquivar registros que estão prestes a ser reestruturados ou removidos.src/logic-functions/pre-install.ts
- Funções de pré-instalação usam
definePreInstallLogicFunction()— a mesma configuração especializada da pós-instalação, apenas anexada a um ponto diferente do ciclo de vida. - Os manipuladores de pré e pós-instalação recebem o mesmo tipo
InstallPayload:{ previousVersion?: string; newVersion: string }. Importe-o uma vez e reutilize-o para ambos os hooks. - Quando o hook é executado: posicionado imediatamente antes da migração de metadados do workspace (
synchronizeFromManifest). Antes de executar, o servidor realiza uma “sincronização simplificada” puramente aditiva que registra a função de pré-instalação da nova versão nos metadados do workspace — nada mais é alterado — e então a executa. Como essa sincronização é apenas aditiva, os objetos, campos e dados da versão anterior ainda estão intactos quando seu manipulador é executado: você pode ler e fazer backup com segurança do estado pré-migração. - Modelo de execução: a pré-instalação é executada de forma síncrona e bloqueia a instalação. Se o manipulador lançar uma exceção, a instalação é abortada antes que quaisquer alterações de esquema sejam aplicadas — o workspace permanece na versão anterior em um estado consistente. Isto é intencional: a pré-instalação é sua última chance de recusar uma atualização arriscada.
- Assim como na pós-instalação, é permitida apenas uma função de pré-instalação por app. Ela é anexada ao manifesto do aplicativo sob
preInstallLogicFunctionautomaticamente durante o build. - Não é executada no modo de desenvolvimento: igual à pós-instalação — o fluxo de instalação é totalmente ignorado para apps registrados localmente, portanto a pré-instalação nunca é executada com
yarn twenty dev. Useyarn twenty exec --preInstallpara acioná-lo manualmente.
Pré-instalação vs pós-instalação: quando usar cada um
Escolhendo o hook de instalação correto
Pré-instalação vs pós-instalação: quando usar cada um
Escolhendo o hook de instalação correto
Ambos os hooks fazem parte do mesmo fluxo de instalação e recebem o mesmo A pré-instalação é sempre síncrona (ela bloqueia a instalação e pode abortá-la). A pós-instalação é assíncrona por padrão — enfileirada em um worker com novas tentativas automáticas — mas pode optar por execução síncrona com Use Regra geral:
InstallPayload. A diferença é quando eles são executados em relação à migração de metadados do workspace, e isso muda quais dados eles podem manipular com segurança.shouldRunSynchronously: true. Veja o acordeão definePostInstallLogicFunction acima para saber quando usar cada modo.Use post-install para qualquer coisa que precise que o novo esquema exista. Este é o caso mais comum:- Popular dados padrão (criando registros iniciais, visualizações padrão, conteúdo de demonstração) em objetos e campos recém-adicionados.
- Registrar webhooks com serviços de terceiros agora que o app tem suas credenciais.
- Chamar sua própria API para finalizar a configuração que depende dos metadados sincronizados.
- Lógica idempotente de “garantir que isso exista” que deve reconciliar o estado em cada atualização — combine com
shouldRunOnVersionUpgrade: true.
PostCard padrão após a instalação:src/logic-functions/post-install.ts
pre-install quando uma migração, de outra forma, destruiria ou corromperia dados existentes. Como a pré-instalação roda contra o esquema anterior e sua falha reverte a atualização, é o lugar certo para qualquer coisa arriscada:- Fazer backup de dados que estão prestes a ser removidos ou reestruturados — por exemplo, você está removendo um campo na v2 e precisa copiar seus valores para outro campo ou exportá-los para um armazenamento antes que a migração seja executada.
- Arquivar registros que uma nova restrição invalidaria — por exemplo, um campo está se tornando
NOT NULLe você precisa excluir ou corrigir linhas com valores nulos primeiro. - Validar a compatibilidade e recusar a atualização se os dados atuais não puderem ser migrados de forma limpa — lance uma exceção no manipulador e a instalação é abortada sem alterações aplicadas. Isto é mais seguro do que descobrir a incompatibilidade no meio da migração.
- Renomear ou reatribuir chaves de dados antes de uma alteração de esquema que perderia a associação.
src/logic-functions/pre-install.ts
| You want to… | Usar |
|---|---|
| Popular dados padrão, configurar o workspace, registrar recursos externos | post-install |
| Executar processos longos de popular dados ou chamadas a terceiros que não devem bloquear a resposta da instalação | post-install (padrão — shouldRunSynchronously: false, com novas tentativas do worker) |
| Executar uma configuração rápida da qual o chamador dependerá imediatamente após o retorno da chamada de instalação | post-install com shouldRunSynchronously: true |
| Ler ou fazer backup de dados que a próxima migração perderia | pre-install |
| Rejeitar uma atualização que corromperia dados existentes | pre-install (lançar uma exceção no manipulador) |
| Executar reconciliação em cada atualização | post-install com shouldRunOnVersionUpgrade: true |
| Fazer uma configuração única apenas na primeira instalação | post-install com shouldRunOnVersionUpgrade: false (padrão) |
Em caso de dúvida, use post-install como padrão. Recurra à pré-instalação somente quando a própria migração for destrutiva e você precisar interceptar o estado anterior antes que ele desapareça.
Clientes de API tipados (twenty-client-sdk)
O pacotetwenty-client-sdk fornece dois clientes GraphQL tipados para interagir com a API do Twenty a partir das suas funções de lógica e componentes de front-end.
| Cliente | Importar | Endpoint | Gerado? |
|---|---|---|---|
CoreApiClient | twenty-client-sdk/core | /graphql — dados do espaço de trabalho (registros, objetos) | Sim, em tempo de dev/build |
MetadataApiClient | twenty-client-sdk/metadata | /metadata — configuração do espaço de trabalho, upload de arquivos | Não, vem pré-compilado |
CoreApiClient
Consultar e modificar dados do espaço de trabalho (registros, objetos)
CoreApiClient
Consultar e modificar dados do espaço de trabalho (registros, objetos)
CoreApiClient é o cliente principal para consultar e mutar dados do espaço de trabalho. Ele é gerado a partir do schema do seu espaço de trabalho durante yarn twenty dev ou yarn twenty build, então é totalmente tipado para corresponder aos seus objetos e campos.true para incluir um campo, use __args para argumentos e aninhe objetos para relações. Você tem preenchimento automático e verificação de tipos completos com base no schema do seu espaço de trabalho.CoreApiClient é gerado em tempo de dev/build. Se você usá-lo sem executar primeiro
yarn twenty dev ou yarn twenty build, ele lançará um erro. A geração ocorre automaticamente — a CLI analisa o schema GraphQL do seu espaço de trabalho e gera um cliente tipado usando @genql/cli.Usando CoreSchema para anotações de tipo
CoreSchema fornece tipos TypeScript que correspondem aos objetos do seu espaço de trabalho — útil para tipar o estado de componentes ou parâmetros de função:MetadataApiClient
Configuração do espaço de trabalho, aplicativos e upload de arquivos
MetadataApiClient
Configuração do espaço de trabalho, aplicativos e upload de arquivos
MetadataApiClient é fornecido pré-compilado com o SDK (não é necessário gerar). Ele consulta o endpoint /metadata para configuração do espaço de trabalho, aplicativos e upload de arquivos.Carregamento de arquivos
MetadataApiClient inclui um método uploadFile para anexar arquivos a campos do tipo arquivo:| Parâmetro | Tipo | Descrição |
|---|---|---|
fileBuffer | Buffer | O conteúdo bruto do arquivo |
filename | string | O nome do arquivo (usado para armazenamento e exibição) |
contentType | string | Tipo MIME (padrão para application/octet-stream se omitido) |
fieldMetadataUniversalIdentifier | string | O universalIdentifier do campo do tipo de arquivo no seu objeto |
- Usa o
universalIdentifierdo campo (não o ID específico do espaço de trabalho), de modo que seu código de upload funcione em qualquer espaço de trabalho onde seu app esteja instalado. - A
urlretornada é uma URL assinada que você pode usar para acessar o arquivo enviado.
Quando seu código é executado no Twenty (funções de lógica ou componentes de front-end), a plataforma injeta credenciais como variáveis de ambiente:
TWENTY_API_URL— URL base da API do TwentyTWENTY_APP_ACCESS_TOKEN— Chave de curta duração com escopo para o papel de função padrão do seu aplicativo
process.env automaticamente. As permissões da chave de API são determinadas pelo papel referenciado em defaultRoleUniversalIdentifier no seu application-config.ts.