> ## 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. # Plano e uso do club > O que o club assina, o ciclo corrente e o uso de cada recurso. ## OpenAPI ````yaml GET /v1/clubs/{clubId}/billing 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: outgoing-webhooks - name: sales-platforms - name: catalog - name: content - name: classroom - name: community - name: mentorships - name: agents - name: lives - name: students - name: auth - name: campaigns - name: workflows - name: email - name: exports - name: certificates paths: /v1/clubs/{clubId}/billing: parameters: - $ref: '#/components/parameters/OrgId' get: tags: - clubs summary: O plano e o uso do club description: | O que o club assina, o ciclo de uso corrente e, por recurso, o que ele tem e o quanto usou. É leitura: o que o club TEM é decidido por quem cobra, fora deste contrato. Com `managed` falso o club ainda não tem plano — tudo é medido e nada é recusado, e `plan` vem nulo. O ciclo de uso é MENSAL mesmo no plano anual: a franquia é por mês. operationId: getClubBilling responses: '200': description: O plano e o uso content: application/json: schema: $ref: '#/components/schemas/ClubBilling' '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: ClubBilling: type: object required: - managed - period_start - period_end - plan - addons - resources properties: managed: type: boolean description: Se o club está sob limites. Falso é o club que ainda não tem plano. period_start: type: string format: date-time period_end: type: string format: date-time plan: nullable: true allOf: - $ref: '#/components/schemas/BillingProduct' addons: type: array items: $ref: '#/components/schemas/BillingProduct' resources: type: array items: $ref: '#/components/schemas/BillingResource' BillingProduct: type: object required: - key - name properties: key: type: string example: plan_linen name: type: string example: Linho BillingResource: type: object required: - key - name - kind - granted - unlimited - allowance - balance - used - overage - bills properties: key: type: string example: campaign_sends name: type: string example: Envios de campanha kind: $ref: '#/components/schemas/BillingResourceKind' granted: type: boolean description: > Se o club tem o recurso. Num `flag`, é a resposta inteira. Nos outros, separa "acabou a franquia" de "não contratou". unlimited: type: boolean allowance: type: integer format: int64 description: > A franquia do ciclo (ou, num `gauge`, o teto). Bytes em espaço e consumo de vídeo, pessoas-minuto em live, unidade simples no resto. Não vale com `unlimited`. balance: type: integer format: int64 description: >- O que resta de saldo avulso — pacote comprado ou cortesia. Gasta-se depois da franquia. used: type: integer format: int64 description: O total do ciclo num `metered`; o tamanho de agora num `gauge`. overage: type: integer format: int64 description: O que passou da franquia e dos saldos, e é cobrado à parte. bills: type: boolean description: | O que acontece quando o que há acaba: verdadeiro cobra o excedente, falso recusa o uso. 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 BillingResourceKind: type: string enum: - flag - gauge - metered description: > Como o recurso se mede. `flag` é ter ou não ter; `gauge` é estoque — o tamanho de agora, como o número de alunos; `metered` é fluxo — o total do ciclo, que zera quando ele vira. 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 - [Uso de IA do club](/api-reference/agents/ai-usage.md) - [Plano do mentorado](/api-reference/mentorships/plan-get.md) - [Limites de uso](/essentials/rate-limits.md) - [Exclui várias mídias](/api-reference/media/batch-delete.md) - [Acesso ao classroom](/api-reference/clubs/classroom-session.md)