O que os workflows mandam em meu nome (registro por versão)

GET/api/workflows/sender-approvals

Auth: Jeton requis
Clé d’API:: workflows:read
X-CommunityId: X-CommunityId Envoyez le X-CommunityId de la communauté où l’opération a lieu.

Les descriptions des endpoints viennent directement de la spécification de l’API et sont en portugais pour l’instant. L’interface autour est traduite.

(decisão do David, 2026-10-26). Para a pessoa logada da equipe: cada versão de workflow que manda DM, comenta ou reage em nome dela fica registrada aqui, com os textos e quem a ligou ou publicou (`requestedById`). A aprovação por versão saiu: o registro já nasce `APPROVED` e nada fica pendente nem é pulado por falta de aprovação; nenhum e-mail pede aprovação. Use `status=ALL` (ou `APPROVED`) para ver o histórico; o padrão `PENDING` volta vazio para versões novas.

Paramètres

Nom	Emplacement	Type	Description
`status`facultatif	query	`PENDING \| APPROVED \| REVOKED \| ALL`

En-têtes

Nom	Type	Description
`X-CommunityId`facultatif	`string (uuid)`	ID da comunidade em que a operação acontece. Obrigatório na maioria dos endpoints com escopo de comunidade.

Réponses

Statut	Description
`200`	`{ approvals: [{ id, workflowId, workflowName, versionId, versionNumber, status, texts: [{ nodeId, type, text?, reaction? }], requestedById, approvedAt, revokedAt, createdAt }] }`.
`401`	Token ausente, inválido ou expirado; token de outra comunidade (o `X-CommunityId` ou o `communityId` do corpo não é o do token); token antigo ou de uma sessão encerrada (troca de senha, convite aceito). Nesses casos a mensagem pede para entrar de novo (`auth.signInAgain`).
`403`	Autenticado, mas sem permissão para esta operação.
`500`	Erro interno do servidor.

Exemple curl

curl -X GET "https://api.memberfy.net/api/workflows/sender-approvals" \
  -H "Authorization: Bearer $TOKEN" \
  -H "X-CommunityId: $COMMUNITY_ID"