> ## Documentation Index > Fetch the complete documentation index at: https://docs.weve.cx/llms.txt > Use this file to discover all available pages before exploring further. # Histórico de eventos > O que as plataformas mandaram e o que o processamento concluiu de cada evento. ## OpenAPI ````yaml GET /v1/clubs/{clubId}/platform-events openapi: 3.0.3 info: title: weve API description: > Contrato entre a API Go e o dashboard. **Este arquivo é a fonte de verdade**: os tipos e a interface de servidor em Go, e o client TypeScript, são todos gerados daqui (`make openapi`). Handler que divergir da interface não compila. A superfície interna (`/internal/*`) fica de fora de propósito: é acesso de máquina, protegido por segredo dedicado, e não é contrato de cliente. version: 0.2.0 servers: - url: https://api.weve.cx description: produção - url: http://localhost:8080 description: desenvolvimento security: [] tags: - name: health - name: session - name: account - name: clubs - name: members - name: webhooks - name: sales-platforms - name: catalog - name: content - name: classroom - name: students - name: auth paths: /v1/clubs/{clubId}/platform-events: parameters: - $ref: '#/components/parameters/OrgId' get: tags: - sales-platforms summary: Histórico de eventos das plataformas description: | Tudo que as plataformas mandaram para este club, mais recente primeiro, com o que o processamento concluiu de cada um. É por aqui que se vê o que ficou parado (`unmatched`), o que falhou (`failed`) e o que ainda não foi processado (`pending`). Sem o corpo: ele sai na leitura de um evento. Paginação por `limit` e `page`. operationId: listPlatformEvents parameters: - name: status in: query required: false description: Filtra pelo resultado. `pending` é o que ainda está na fila. schema: $ref: '#/components/schemas/PlatformEventStatus' - name: connection_id in: query required: false schema: type: string format: uuid - name: limit in: query required: false schema: type: integer minimum: 1 maximum: 100 default: 25 - name: page in: query required: false schema: type: integer minimum: 1 default: 1 responses: '200': description: A página pedida content: application/json: schema: $ref: '#/components/schemas/PlatformEventList' '401': $ref: '#/components/responses/Unauthorized' '403': $ref: '#/components/responses/Forbidden' '500': $ref: '#/components/responses/InternalError' security: - userSession: [] components: parameters: OrgId: name: clubId in: path required: true description: > Id público da organização — o mesmo que `GET /v1/me` devolve em `organization_id`. Na URL o recurso se chama **club**; no contrato e no domínio, organization. A divergência é deliberada: `clubs` é a palavra do produto, e a URL é o que as pessoas leem. É o identificador do provedor de autenticação, e é assim de propósito: o cliente precisa nomear a organização ao pedir o token, e o token é o que prova o escopo. Um id só nosso obrigaria a traduzir um no outro antes de ter um token — e a tradução exigiria uma chamada escopada, que é justamente a que ainda não dá para fazer. O uuid interno da organização não aparece no contrato: ele é o que as chaves estrangeiras do domínio referenciam, e continua sendo nosso. schema: type: string format: uuid schemas: PlatformEventStatus: type: string enum: - pending - applied - ignored - unmatched - failed description: | `pending` ainda não foi processado; `applied` mudou acesso; `ignored` não tinha o que mudar; `unmatched` espera algo que ainda não chegou (a compra de um reembolso, o mapeamento de um produto); `failed` esgotou as tentativas ou não deu para ler. PlatformEventList: type: object required: - data properties: data: type: array items: $ref: '#/components/schemas/PlatformEvent' PlatformEvent: type: object required: - id - connection_id - platform - status - attempts - received_at properties: id: type: string format: uuid connection_id: type: string format: uuid platform: $ref: '#/components/schemas/SalesPlatform' event_type: type: string description: O nome do evento como a plataforma o chama. external_event_id: type: string transaction_id: type: string description: >- A venda a que o evento se refere, quando o processamento a identificou. status: $ref: '#/components/schemas/PlatformEventStatus' notice: type: string description: | O que o processamento tem a dizer: o motivo de um `unmatched`, o erro de um `failed`, o aviso de um `ignored`. attempts: type: integer received_at: type: string format: date-time processed_at: type: string format: date-time next_attempt_at: type: string format: date-time description: Só em `pending` com falha anterior — quando a fila tenta de novo. ErrorEnvelope: type: object description: >- Envelope único de erro da API. O `code` é o contrato com o cliente — a `message` é diagnóstico, e pode mudar. required: - error properties: error: type: object required: - code properties: code: type: string message: type: string SalesPlatform: type: string enum: - hotmart - kiwify - eduzz - guru - webhook description: | As plataformas de venda que a API entende. `guru` é o Digital Manager Guru; `webhook` é o formato genérico, para gateways e automatizadores sem integração nativa. responses: Unauthorized: description: Sessão ausente, expirada ou revogada content: application/json: schema: $ref: '#/components/schemas/ErrorEnvelope' Forbidden: description: > A sessão é válida, mas não age nesta organização. É a mesma resposta para uma organização que não existe — distinguir as duas deixaria enumerar organizações alheias. content: application/json: schema: $ref: '#/components/schemas/ErrorEnvelope' InternalError: description: >- Falha inesperada. O corpo nunca traz o erro real — ele fica no log e no rastreamento. content: application/json: schema: $ref: '#/components/schemas/ErrorEnvelope' securitySchemes: userSession: type: http scheme: bearer description: | Token OPACO de sessão de quem administra, emitido por `/v1/auth/admin/sign-in` e verificado contra a nossa tabela — o mesmo desenho do `studentSession`, para a outra identidade. É o esquema de quem ADMINISTRA — o dashboard. O aluno do classroom usa o `studentSession`; uma rota consumida pelos dois declara os dois esquemas, e o middleware aceita qualquer um deles. As duas credenciais são opacas e chegam pelo mesmo cabeçalho: quem as separa é a tabela em que cada uma existe. O dashboard o guarda em cookie httpOnly, que o BFF troca pelo `Authorization` a cada chamada. ```` ## Related topics - [Desligar conexão](/api-reference/webhooks/connections-disable.md) - [Receber evento de plataforma](/api-reference/webhooks/receive.md) - [Reprocessar evento](/api-reference/webhooks/events-reprocess.md) - [Ler um evento](/api-reference/webhooks/events-get.md) - [Ler aluno](/api-reference/students/get.md)