Auditoria da API do TikTok: como passar

Um cliente não auditado é aquele que ainda não foi revisado e aprovado pelo TikTok para publicação voltada ao público. Todo app começa aqui, e a maioria consegue publicar conteúdo real nesse estado — a restrição é sobre visibilidade e volume, não sobre a API funcionar ou não.

O TikTok aplica isso no nível da conta: toda conta de usuário que publica por um cliente não auditado precisa estar configurada como privada no momento da publicação. Isso não é opcional e não é algo que o seu app possa contornar do lado do cliente.

Conteúdo publicado por um cliente não auditado é forçado para visibilidade SELF_ONLY, independente da opção de privacidade que o usuário escolheu na interface do seu app ou na tela de consentimento do TikTok — as diretrizes de compartilhamento de conteúdo do TikTok afirmam isso diretamente. Para tornar um post específico visível publicamente depois, o dono da conta precisa trocar manualmente a conta do TikTok para pública e então mudar a privacidade daquele post individual para "Todos" — uma ação manual de dois passos que a sua integração não consegue fazer em nome do usuário.

Clientes não auditados também têm um teto de até 5 usuários publicando dentro de uma janela móvel de 24 horas, segundo as mesmas diretrizes. Isso é um limite duro para o seu piloto não auditado, não um rate limit flexível que você pode pedir para aumentar sem se candidatar à auditoria.

Passar na auditoria não remove todo limite. Tanto clientes auditados quanto não auditados estão sujeitos a um teto de criadores ativos em 24 horas, dimensionado a partir das estimativas de uso que você fornece na sua candidatura de auditoria — subestimar o seu volume de lançamento ali e você ainda pode ser limitado depois da auditoria. Também existe um teto diário de publicações por criador via Direct Post API — a própria orientação do TikTok o descreve como tipicamente em torno de 15 posts por conta de criador por dia, ressalvando que o limite superior exato pode variar por criador — e esse teto se aplica independente do status de auditoria.

A liberação principal é visibilidade: um cliente auditado consegue publicar conteúdo visível publicamente de imediato, sem o contorno de post privado. Também remove o teto móvel de 5 usuários, substituindo-o pelo teto de criadores dimensionado ao uso declarado na sua candidatura. A auditoria não aumenta o teto diário de publicações por criador — esse limite é estrutural, não uma consequência do status de revisão.

Para um time construindo uma integração de publicação, o nível não auditado é suficiente para construir, demonstrar e pilotar com um grupo pequeno de testadores que consentem — desde que eles entendam que os posts saem privados até que alguém os republique manualmente. Não é suficiente para um lançamento público: forçar cada cliente real a republicar manualmente cada post anula o sentido de uma ferramenta de publicação automatizada.

O padrão que a maioria dos times adota: construir e validar internamente contra o nível não auditado primeiro, já que a própria superfície da API não muda depois da auditoria — só os tetos e a visibilidade padrão mudam. Submeter para auditoria quando a integração estiver completa, usando estimativas de uso reais (mesmo que conservadoras), para que o teto de criadores que você recebe realmente cubra o seu lançamento. Trate a janela de revisão de auditoria como uma trilha paralela, não um bloqueio que trava o resto do trabalho.

Exponha o status de auditoria explicitamente no seu próprio produto, em vez de deixar o cliente descobrir o comportamento de post privado por acidente — um estado claro de "publicando em modo limitado/privado" é bem melhor do que um chamado de suporte sobre um post "quebrado". E construa o tratamento de status de entrega em cima do resultado por destino de cada publicação, não só de uma flag agregada de sucesso/falha, para você distinguir um post que realmente falhou de um que publicou corretamente mas saiu privado por design.