API de Dashboard

Inspeciona um convite sem consumi-lo. Nunca reporta estado de cadastro ou verificação, exceto que um reset de login reporta replaces_unverified_account. Um convite organization_admin ou organization_member informa o nome da organização e nenhum projeto.

Inicia uma cerimônia de registro de cinco minutos vinculada ao resumo e modo do convite. Link create_login requer cookie __Host-screenrig-signup verificado e usa seu nome.

Email create_login vincula o nome de exibição fornecido; reset vincula a pessoa alvo, exceto que um reset de um endereço não verificado registra a passkey para a nova pessoa que ele cria, nomeada pelo nome de exibição fornecido ou, quando ausente, a partir do endereço.

Esse reset exige replace_unverified_account true (a inspeção informa replaces_unverified_account) e, caso contrário, responde 409 unverified_account_replacement.

Inicia um cadastro vinculado ao navegador e revoga cadastros anteriores para este convite. O desafio de verificação está vinculado a este cadastro. Autenticação de desenvolvimento verifica o cadastro imediatamente sem e-mail.

Retorna o cadastro ao vivo pertencente a este navegador. Um cookie de cadastro ausente, revogado, consumido ou expirado retorna invitation_invalid.

Aceita um convite transacionalmente e cria uma nova sessão de pessoa, excluindo a sessão antiga quando presente.

Link create_login requer o cookie verificado __Host-screenrig-signup para este convite. signed_in requer uma sessão do dashboard e login recente ou prova nova; a entrega por e-mail requer um e-mail verificado correspondente ou o endereço não verificado da pessoa que fez login, que a aceitação verifica.

Um endereço que uma pessoa ativa já possui, verificado ou não, retorna resource_conflict para create_login. Um reset autentica a pessoa que possui um endereço verificado.

Um reset de um endereço não verificado exige replace_unverified_account true (a inspeção informa replaces_unverified_account) e, caso contrário, responde 409 unverified_account_replacement e não consome nada; com ele, o reset cria uma nova pessoa verificada com a credencial que ele registra, nomeada por display_name ou, quando ausente, a partir do endereço, com uma nova organização e um novo projeto, e autentica essa pessoa; a pessoa não verificada é excluída (suas sessões, passkeys e agentes são encerrados) e os projetos e organizações que ela criou permanecem, sem ela e sem mais corresponder ao endereço como contato, de modo que nenhum reset posterior reenvia um convite de inscrição para eles.

A resposta nomeia o novo projeto. Uma sessão que exige verificação de e-mail (email_verification_required em GET /api/session) aceita apenas um convite enviado por e-mail que nomeie o próprio endereço e recebe 403 email_verification_required para qualquer outro.

Um convite organization_admin adiciona a pessoa aos administradores da organização e não abre nenhum projeto; retorna organization_admin_limit quando a organização já tem 20 administradores e permanece pendente, e resource_conflict quando a organização foi excluída.

Um convite organization_member define a organização principal da pessoa como a organização que convida, substituindo qualquer organização principal anterior, e não concede associação ao projeto; retorna managed_elsewhere (409) quando outra organização gerencia a pessoa, e resource_conflict quando a organização foi excluída.

Um convite organization_admin define a organização principal somente para uma pessoa que não tem nenhuma. Um convite project_member verifica novamente a política de convidados da organização e retorna guest_not_allowed (403) quando a pessoa seria um convidado externo que a política recusa; um convite de projeto nunca altera a organização principal de ninguém. Um convite recusado permanece pendente.

Inicia uma cerimônia de registro de cinco minutos para um cadastro de autoatendimento, vinculada ao endereço de e-mail normalizado e ao nome de exibição. Não cria nada e não envia e-mail.

Um endereço que uma pessoa ativa possui, verificado ou não, retorna 409 account_exists; um endereço em um domínio cuja organização faz login por meio de um provedor de identidade retorna 403 sso_required; um endereço ou nome inválido retorna 400 invalid_request com erros de campo. Um servidor que executa a autenticação de desenvolvimento do dashboard retorna passkeys_disabled.

Limitado por endereço de cliente.

Cria uma conta de autoatendimento e faz o login deste navegador.

Uma transação cria a pessoa com um endereço de e-mail não verificado e um prazo de verificação de 72 horas, registra a passkey da cerimônia que POST /api/signups/passkey-options iniciou, cria a organização e o projeto da pessoa como a inscrição do agente os cria, torna a pessoa o proprietário do projeto, armazena a escolha sobre e-mails de marketing e enfileira o e-mail de verificação (purpose account_email).

O visitante do site que abriu a página é vinculado à conta e o cadastro é contado como signed_up. A resposta define o cookie de sessão do dashboard. As recusas são as de POST /api/signups/passkey-options; uma cerimônia usada, expirada ou incompatível retorna 400 invalid_request. Limitado por endereço de cliente e por endereço de e-mail.

Alterna para um dos projetos da pessoa e atualiza seu último uso. Um membro da equipe também pode alternar para um projeto que eles monitoram; essa sessão indica shadow true, é somente leitura e não atualiza o último uso. Qualquer outro projeto retorna not_found.

Lista membros do projeto atual sem seus endereços de e-mail privados.

Todo membro tem a mesma autoridade, exceto o gerenciamento de membros (remoção, aprovador, escopos, propriedade), que cabe ao proprietário e a um administrador da organização do projeto que seja membro. owner marca o proprietário do projeto, external marca um convidado (a organização principal do membro não é a organização do projeto), e viewer_user_id e viewer_is_owner descrevem a pessoa com a sessão iniciada.

Remove um membro do projeto atual. O proprietário do projeto remove qualquer outro membro, assim como um administrador da organização do projeto que é membro; qualquer membro remove a si mesmo para sair. O proprietário nunca é removido e nunca sai (owner_cannot_leave; transfira a propriedade primeiro). Um membro removendo outra pessoa é recusado com owner_required.

Uma pessoa que não é membro, inclusive uma já removida, é not_found. Em uma transação, a associação termina, os convites por e-mail pendentes dessa pessoa para o projeto são revogados, e o evento do projeto member.removed é anexado (detalhes user_id, removed_by_user_id, left).

As sessões da pessoa param de resolver o projeto na próxima solicitação e voltam ao estado padrão como após a exclusão de um projeto. As associações de agentes são separadas e permanecem. Somente pessoas; sem rota bearer.

A atividade de uma pessoa no projeto atual, as mais recentes primeiro: seus acessos (e acessos recusados nomeando seu endereço ou passkey), saídas, trocas para o projeto, mudanças de credenciais, provas de reautenticação e cada mudança que fizeram pelo painel, incluindo recusadas e falhas. Leituras nunca são registradas.

Solicitações do agente e CLI estão em seus agentes (listDashboardAgentEvents). A sombra de um membro da equipe do projeto não registra nada; uma alteração feita sob um contrato de escrita aprovado de um membro da equipe é uma linha desse membro da equipe com origem na equipe.

A própria pessoa, o proprietário do projeto, um admin da organização do projeto e um membro da equipe acompanhando o projeto podem ler. Qualquer outro recebe not_found, assim como uma pessoa que não é membro nem tem linhas aqui, então a resposta nunca revela quem pertence; linhas de ex-membros permanecem legíveis.

O projeto é da sessão, nunca da solicitação, e apenas as linhas desse projeto são retornadas.

Cada valor é derivado do servidor: a ação da rota que o servidor correspondeu (ou uma ação de conta nomeada como session.sign_in ou passkey.add), o recurso do primeiro valor do caminho da rota quando é um identificador emitido pelo servidor, status, problem_code e erro do registro de problemas, o cliente analisado do User-Agent e dica de plataforma (o User-Agent bruto não é mantido).

Nenhum corpo de solicitação, senha, token ou cookie é armazenado. client_ip e email são exibidos conforme registrados.

Chaves de paginação em (at, id) descendente. Passe next_cursor como after para continuar; é nulo no fim. Uma linha escrita enquanto isso só aparece antes da primeira página e retenção remove as linhas mais antigas, então um cursor nunca repete ou pula uma linha sobrevivente. Cursor ou filtro malformado é recusado com invalid_request; limite fora de 1-100 é padrão.

As linhas expiram na janela de retenção de eventos do projeto no momento em que foram escritas. recorded_since é o tempo da linha mais antiga sobrevivente do projeto ou, antes de qualquer uma, quando este servidor começou a registrar; nada antes disso é reconstruído.

Retorna o perfil da pessoa conectada e contagem de credenciais.

Marca para exclusão a pessoa conectada. Protegido por prova: o corpo carrega uma prova de login recente verificada contra uma reautenticação vinculada a esta sessão com tipo account_delete e subject_id igual ao id do usuário da pessoa conectada (inicie com POST /api/me/reauthentications). Sem reautenticação atual, a resposta é reauthentication_required.

Em caso de sucesso, a resposta é 204, o cookie de sessão do dashboard é limpo e o cache HTTP do navegador para a origem do dashboard é limpo como ao sair.

Inicia o passo-up passkey vinculado à sessão, tipo e assunto. Pessoa sem passkey recebe resource_conflict e usa prova de senha.

Define ou substitui a senha da pessoa após prova recente. A primeira senha requer prova de passkey; substituição aceita a senha atual ou uma passkey. Revoga outras sessões e enfileira um aviso de alteração de login.

Uma pessoa cujo endereço de e-mail não foi verificado, como um cadastro de autoatendimento antes de a pessoa verificá-lo, não pode definir uma senha e recebe 403 email_verification_required.

Lista as passkeys da pessoa com o que um cliente precisa para manter o gerenciador de senhas do navegador em sincronia com elas (a WebAuthn Signal API). A lista traz o ID da parte confiável e o identificador de usuário (user handle) sob os quais as passkeys estão registradas, e cada passkey traz o seu ID de credencial e o provedor informado pelo autenticador dela.

Verifica prova recente e inicia um registro vinculado à sessão e pessoa. Passkeys estão desativadas sob autenticação em desenvolvimento.

Armazena a nova passkey, revoga as outras sessões da pessoa e enfileira uma notificação de alteração de login. Uma passkey enviada sem nome recebe o nome do seu provedor, ou Passkey quando o autenticador não informou nenhum provedor que a lista conheça.

Renomeia um passkey pertencente à pessoa conectada.

Exclui uma passkey após prova recente e envia uma notificação de alteração de login. Remover o último método de login retorna last_credential. Uma pessoa cuja conta requer passkey (todo membro da equipe) não pode remover sua última passkey; isso retorna 409 resource_conflict.

Retorna o estado do e-mail verificado e pendente da pessoa. Uma pessoa que se cadastrou por conta própria mantém um endereço não verificado até abrir o link enviado a ele; email_verified é false e verify_by é o prazo, após o qual a sessão pode usar apenas as rotas que verificam ou alteram o endereço (email_verification_required em GET /api/session).

Solicita uma alteração de e-mail após prova nova. O endereço verificado continua em vigor enquanto a verificação está pendente. Um endereço que qualquer outra pessoa ativa possui, verificado ou não, retorna user_email_conflict. O endereço antigo recebe um aviso, não um link para desfazer.

Uma pessoa cujo endereço não foi verificado o altera da mesma forma; verificar o novo endereço o torna o endereço verificado da pessoa e limpa verify_by.

Enfileira um novo link de verificação. Enquanto uma alteração de e-mail aguarda verificação (pending_email em GET /api/me/email), ele é o link dessa alteração, enviado ao endereço pendente; caso contrário, é um link account_email para o endereço atual não verificado da pessoa. Até dez minutos depois do último link do mesmo tipo, não enfileira nada e ainda responde 202.

Uma pessoa cujo endereço é verificado e que não tem alteração pendente retorna 409 resource_conflict.

Substitui as respostas que a pessoa deu após o cadastro pelo corpo, que contém todas as respostas até agora; um membro omitido, ou null, fica sem resposta. Cada membro tem um conjunto fechado de valores, e um valor fora dele retorna 400 invalid_request com um erro de campo.

O perfil é mantido junto com a pessoa e exibido à equipe do screenRIG com a organização na qual a pessoa se cadastrou.

Onde um aplicativo (app web) do projeto da sessão é posicionado, calculado em uma única passagem pelas playlists do projeto e uma leitura das telas que as têm. placements são as primitivas de aplicativo cujo aplicativo proprietário armazenado é este aplicativo, em ordem de playlist (a ordem da lista de playlists), página e primitiva; uma playlist que o posiciona duas vezes tem dois. release informa como cada versão fixada se compara com a latest_ready_release do aplicativo: latest, older ou unknown enquanto ele não tem nenhuma. screens são as telas pairing_pending e ativas que têm uma playlist de um posicionamento como padrão, a agendam, a usam em um takeover ou a exibem no momento, as mais recentes primeiro; telas arquivadas nunca contam, e uma tela cujo Player não consegue exibir apps web carrega applications_unsupported.

Um membro ou agente limitado a telas (screen_scope) vê apenas as suas telas, e screen_count conta somente essas. Isso não é o que bloqueia a exclusão, que são as concessões de runtime (o manifesto de uma tela que contém uma versão). Um id que o projeto não tem é not_found, como em getApplication. A resposta é privada e no-store.

Onde um item de mídia pronto do projeto da sessão é usado, calculado em uma única passagem pelas playlists do projeto e uma leitura das telas que as têm. playlists são as que nomeiam o arquivo (os ids estáticos de uma primitiva de imagem ou vídeo e um seletor por id ou ids, o fallback de um stream, uma string media:<id> nos params de um cartão, o logo de um stinger, uma faixa de trilha sonora), depois as cujos seletores tag, folder ou all o alcançam, cada grupo na ordem da lista de playlists; uma playlist é uma entrada cujo uses lista cada forma, os tipos exatos primeiro.

Os seletores são avaliados como o runtime os resolve: um filtro de tag corresponde à tag e às tags do arquivo, um seletor de pasta aos arquivos diretamente dentro da pasta, um seletor all a todos os arquivos do tipo, e um arquivo pendente pelas suas últimas tags e pasta aprovadas (um arquivo nunca aprovado não é alcançado por nenhum).

Rotação (batch_size, one_at_a_time), janelas de disponibilidade, ajuste de proporção e a visibilidade de uma página não são avaliados. screens são as telas pairing_pending e ativas que têm uma dessas playlists como padrão, a agendam, a usam em um takeover ou a exibem no momento, as mais recentes primeiro; telas arquivadas nunca contam.

Um membro ou agente limitado a telas (screen_scope) vê apenas as suas telas, e screen_count conta somente essas. Um id que o projeto não tem, ou um item de mídia que não está pronto, é not_found, como em getMedia. A resposta é privada e no-store.

Retorna um pequeno WebP com perda de qualidade de uma imagem pronta pertencente ao projeto da sessão, para que as grades do painel nunca decodifiquem originais. Há um tamanho: cabe dentro de 512 x 512 mantendo a proporção e nunca é ampliado, e uma imagem animada mostra seu primeiro quadro.

A primeira solicitação a gera e armazena ao lado do original; solicitações posteriores transmitem a cópia armazenada, e excluir o mídia remove-a junto com o original. O identificador de outro projeto, vídeo, áudio e mídia que não está pronto retornam not_found. Range não é aceito.

O ETag é forte e nomeia o original e o gerador de miniaturas, então é o mesmo em toda requisição e host. A resposta é privada, no-cache, e um If-None-Match que corresponde, verificado após a mídia resolver no projeto da sessão, retorna 304 sem ler a miniatura. Bytes completos são registrados como egressos dashboard_media.

Aplica as mesmas regras de propriedade, condicionais e geração que getDashboardMediaThumbnail e retorna seus cabeçalhos sem o corpo. Nenhuma saída é registrada.

Verificação segura para scanner. Nunca verifica um endereço, altera um usuário ou autentica o visitante. Informa o propósito e o estado do link; um link account_email pendente só verifica para uma requisição que traga a sessão do dashboard da pessoa, então uma página pede o login antes de pedir a confirmação.

A confirmação humana explícita consome um desafio de verificação vinculado a um propósito. Os desafios de cadastro por link requerem o cookie __Host-screenrig-signup correspondente; os desafios de alteração de e-mail são vinculados a token, portanto o link funciona em qualquer navegador.

Um desafio account_email (enviado por e-mail no cadastro de autoatendimento e por POST /api/me/email/verification, válido por 30 dias) abre em qualquer navegador, mas só verifica para uma requisição que traga uma sessão ativa do dashboard da pessoa a quem o link se destina, inclusive uma sessão que email_verification_required limita a esta rota.

Sem sessão, ou com a de outra pessoa, responde 200 sign_in_required, não verifica nada e deixa o link utilizável. Um link account_email verificado marca o endereço da pessoa como verificado e encerra o prazo de verificação; responde superseded quando outra pessoa verificou o mesmo endereço primeiro. A verificação nunca autentica o visitante.

Inicia uma cerimônia de afirmação WebAuthn sem nome de usuário e retorna as opções de requisição literalmente para navigator.credentials.get. Nenhum cookie é necessário, e nenhuma lista allowCredentials é publicada, então a rota não revela quais usuários ou credenciais existem. A cerimônia expira com DashboardCeremonyTTL de cinco minutos.

Quando o servidor executa autenticação de desenvolvimento do dashboard, esta rota retorna passkeys_disabled.

Verifica uma asserção sem nome de usuário e cria o cookie de sessão do dashboard para o usuário identificado pela credencial descobrível. Nenhum cookie autentica a solicitação. Uma cerimônia desconhecida, expirada ou já usada retorna passkey_invalid, assim como uma asserção que a parte confiável não pode verificar ou um contador de assinatura que retrocede.

Uma cerimônia válida cujo identificador de credencial não está registrado para ninguém (nenhuma credencial armazenada o tem, de nenhuma pessoa) retorna, em vez disso, 401 passkey_unknown; essa resposta vale somente para esse único caso, então um cliente pode instruir o navegador a esquecer a credencial (PublicKeyCredential.signalUnknownCredential) com base nela e em nenhuma outra.

O identificador da credencial não é autorização por si só: a asserção assinada é. Uma pessoa cujo endereço verificado está em um domínio cuja organização exige login único é recusada com 403 sso_required, a menos que seja um administrador de emergência (break-glass) dessa organização; esse login é auditado.

Quando o servidor executa autenticação de desenvolvimento do dashboard, esta rota retorna passkeys_disabled.

Faz login da pessoa identificada por e-mail verificado e senha. E-mail desconhecido, sem senha e senha errada retornam a mesma resposta não autorizada. Abre o último projeto usado se ainda for uma associação, caso contrário a associação mais recente, ou nenhum projeto.

Um endereço em um domínio cuja organização exige login único é recusado com 403 sso_required antes de qualquer conta ser consultada, de modo que a resposta não depende de uma pessoa possuir ou não o endereço; POST /api/sso/starts autentica essa pessoa pelo provedor de identidade dela.

O login com senha requer um e-mail verificado; por isso, uma pessoa que se cadastrou por conta própria (POST /api/signups) faz login com a passkey, e quem definiu uma senha em um endereço não verificado ainda recebe a resposta unauthorized. A autenticação de desenvolvimento usa esse mesmo fluxo de senha.

Retorna a sessão atual do dashboard. O cookie de sessão e a sessão do lado do servidor estabelecem autoridade; user_id é descritivo. Uma resposta 401 significa que é necessário entrar.

O campo dev_auth é reservado para desenvolvimento local e é falso no serviço hospedado. organization é a organização principal da pessoa, ausente enquanto ela não tem nenhuma; project.organization_admin informa se a pessoa administra a organização do projeto atual.

Exclui a linha de sessão do lado do servidor e expira o cookie da sessão. Não exclui o usuário nem remove nenhuma credencial. É intrinsecamente idempotente e não aceita Idempotency-Key.

Um logout bem-sucedido também limpa o cache HTTP do navegador para a origem do dashboard, eliminando os bytes privados, sem cache de mídia, screenshot e revisão de anúncios que a sessão visualizou; uma sessão que apenas expira os deixa até o navegador os remover.

Reporta uma etapa do percurso de um navegador pelos fluxos de entrada do dashboard (cadastro, login, redefinição, convite e adição de uma passkey) para a leitura de onboarding da equipe. Acesso público: funciona com e sem uma sessão do dashboard.

A jornada é o id aleatório do próprio navegador; o servidor também guarda o cookie de visitante da edge quando a requisição traz um, e a pessoa e a organização quando há uma sessão. Uma jornada é restrita à equipe e guarda os valores reais que as pessoas informaram (endereços, nomes, respostas); nunca recebe senha, código ou token.

O primeiro valor de mode, source, utm_source, utm_medium, utm_campaign, click_kind, site_trail e site_cta é mantido; cada etapa mantém seu primeiro horário, e o value e o detail de uma etapa e o e-mail da jornada (de email_submitted) são os mais recentes. source é aceito somente com entry_viewed. question é obrigatório com as etapas question_* e recusado com qualquer outra. detail é um código de problema para uma etapa *_failed, o método de login para signed_in, ou connected ou skipped para signup_finished. email_verified, email_gate_reached, site_visited, site_cta_clicked e os marcos da conta são gravados ou derivados pelo servidor e são recusados aqui.

Somente os comprimentos são limitados. Limitado por endereço de cliente.

Lista todos os agentes pendentes, ativos, revogados, cancelados e expirados do projeto da sessão com metadados de instalação segura, último uso, contagem de solicitações autenticadas e créditos medidos diretamente atribuíveis. Nenhum byte de portador, chave do destinatário, envelope ou identificador do projeto é retornado.

Histórico deste agente, do mais recente para o mais antigo, como UM registro por gatilho. Ele contém tanto o que o agente solicitou quanto o que mudou como resultado. Uma solicitação que mudou algo é seu evento de domínio, marcado com o comando que o causou. Uma solicitação que não mudou nada — recusada, falhou ou um sucesso sem evento — é um evento agent.command.

Não há endpoint separado para comandos; mostrar o mesmo gatilho em dois painéis era o defeito que isso substituiu. Eventos de ciclo de vida para este agente estão incluídos. Atividade apenas de worker, player e dashboard nunca é inferida como atividade do agente. Duas solicitações são dois gatilhos. Uma nova tentativa após recusa é um segundo registro, nunca uma reescrita do primeiro.

Leituras não são registradas, porque não mudam nada e um agente de polling enterraria toda ação real. Inscrição anônima é excluída. Cada parte do carimbo do comando é derivada da rota que este servidor correspondeu ou do registro de problemas.

Não há vetor de argumento, corpo de solicitação, cabeçalho ou texto livre em qualquer registro, então nada precisa ser ocultado e nenhum chamador pode escrever texto escolhido em uma superfície visível ao operador. Identificadores de recurso aparecem porque um identificador nunca é autorização e já é publicado em eventos. Chaves de paginação em sequência, descendente.

Passe o next_cursor retornado como after para continuar. next_cursor está vazio quando a página é curta, que é o fim do histórico: um append concorrente só assume uma sequência maior, e a retenção remove as sequências mais baixas primeiro, então um cursor nunca duplica ou pula um registro sobrevivente. Paginação por offset não é suportada.

Cada parâmetro de busca é um predicado de correspondência exata ou intervalo em um token escrito pelo servidor. Um cursor ou valor de filtro malformado é recusado com invalid_request. Um limite fora de 1-200 é ajustado para o padrão em vez de recusado. Registros expiram na janela de retenção de eventos do projeto.

Desconecta o agente do projeto selecionado após prova recente. O projeto deve ser uma das associações da pessoa. Conexões pendentes e emissões de credenciais são canceladas; nenhum token substituto é emitido. Um membro limitado a telas não conecta agentes, não emite credenciais nem gerencia as pessoas do projeto: outside_screen_scope (peça ao proprietário do projeto).

As notas que este agente escreveu no projeto da sessão, mais recentes primeiro, abertas e resolvidas. state é all (padrão), open ou resolved. Passe next_cursor como after; está vazio na última página. Os corpos das notas são texto simples escrito por um agente; renderize como texto, nunca como HTML ou Markdown.

Resolve uma das notas abertas do agente como a pessoa conectada, com um motivo obrigatório; resolution.by nomeia a pessoa. Acrescenta note.resolved com a pessoa como ator. Uma nota resolvida é note_not_open.

Exclui uma das notas do agente, aberta ou resolvida, como a pessoa conectada. Acrescenta note.deleted com a pessoa como ator.

As solicitações de conexão pendentes endereçadas ao projeto da sessão, que um membro pode revisar e aprovar: solicitações nomeando o projeto, e logins ou conexões de dispositivo por uma identidade de agente já membro dele.

O login de uma nova instalação não está listado (sua dica de projeto é fornecida pelo cliente); uma pessoa o acessa pelo código do usuário (POST /api/agent-connections/lookup).

Resolve o código do usuário de um login pendente do dispositivo (`screenrig login`), conforme digitado ou preenchido na página de conexão, para sua conexão, cuja visualização de aprovação então o mostra. Não aprova nada. Separadores, espaços e maiúsculas são ignorados. Um código desconhecido, usado ou inválido é agent_connection_invalid; um expirado é agent_connection_expired.

Limitado a 5 consultas por sessão de dashboard a cada 10 minutos, 20 por endereço de cliente por hora e 1200 por hora em toda a frota (rate_limited). Um membro limitado a telas não conecta agentes, não emite credenciais nem gerencia as pessoas do projeto: outside_screen_scope (peça ao proprietário do projeto).

Retorna metadados de revisão de conexão segura. A revisão não seleciona um projeto; a aprovação seleciona uma das associações da pessoa.

Aprova a conexão para o projeto selecionado após prova recente e cria um agente pendente. O projeto deve ser uma das associações da pessoa. Retorna metadados seguros, nunca o bearer. Um membro limitado a telas não conecta agentes, não emite credenciais nem gerencia as pessoas do projeto: outside_screen_scope (peça ao proprietário do projeto).

Nega a conexão para o projeto selecionado após prova recente, sem criar um agente. O projeto deve ser uma das associações da pessoa. Um membro limitado a telas não conecta agentes, não emite credenciais nem gerencia as pessoas do projeto: outside_screen_scope (peça ao proprietário do projeto).

Uma única requisição para o shell do dashboard.

Cada membro é o corpo que a rota indicada responde para esta mesma sessão (GET /api/me/email, /api/support/status, /api/projects, /api/organizations, /api/project, /api/project/capabilities, /api/advertising/network, /api/alerts?state=open&limit=1 e /api/reviews?state=all&limit=1), produzido pelo handler próprio dessa rota, sob as suas próprias verificações de autorização, plano e escopo.

Um membro fica ausente quando sua rota não responderia 2xx para esta sessão (uma recusa, um papel ou plano que não pode lê-la, nenhum projeto atual, uma falha), e o dashboard então lê essa rota por conta própria. advertising_network é null quando sua rota responderia 404 not_found porque o projeto não tem rede.

Uma sessão sem projeto atual recebe os membros que não precisam de nenhum.

Contadores de status de rede do projeto para o projeto da sessão. Contagens de telas online são derivadas de fluxos de eventos em tempo real pareados, a mesma derivação que Screen.online publica; não são booleanos armazenados nem heartbeat do player. Bytes de mídia são bytes duráveis apenas da mídia pronta.

Estado verdadeiro da capacidade de pagamento. rails_available é falso e unavailable_reason é financial_rails_unavailable enquanto cartão, imposto e via de saque estão indisponíveis. Nenhuma credencial bancária bruta é retornada.

Um recibo/documento fiscal finalizado pertencente ao solicitante. Nenhum recibo existe enquanto a coleta de dinheiro não é enviada, então isto é not_found em vez de um documento fabricado.

Retorna o saldo público de créditos totais do projeto da sessão. Esta leitura autenticada por cookie nunca debita, então permanece disponível em zero. O dashboard somente com cookie nunca apresenta um portador de projeto para GET /api/project.

Cria um único ticket de lançamento de uso único de trinta segundos para a última versão pronta de um aplicativo que o projeto da sessão possui, no host de pré-visualização exato dessa versão, nunca no host de lançamento que os Players usam, para que um Player e o dashboard em um navegador nunca compartilhem os documentos em cache desse host ou concedam cookie.

O ticket se converte no cookie release-grant apenas nesse host, então a pré-visualização é cross-origin por construção e o código da aplicação web nunca pode ler um cookie do dashboard. A resposta release_id identifica a versão exata escolhida para este lançamento, mesmo que outra publicação termine depois. Atribua launch_url a iframe.src e a mais nada.

A autoridade aqui é a autoridade do proprietário: o projeto da sessão é dono da aplicação. Essa é uma fonte deliberada de segunda autoridade ao lado da autoridade exata do manifesto atual para screenrig.webapp-package/v1, e está limitada a esta operação. Não generalize para mídia ou conteúdo protegido do runtime.

Não há player pai, então o SDK do navegador e a ponte chave-valor falham fechados e a pré-visualização é apenas apresentação. Uma aplicação sem versão pronta é resource_conflict.

Uma organização como um item de GET /api/organizations a mostra ao chamador, com admin, home e reseller. Uma pessoa conectada a lê quando a administra, administra o revendedor ao qual ela está delegada, é da equipe, ou a veria nessa listagem (membro de um de seus projetos ativos, ou é sua organização principal).

Qualquer outra pessoa, ou uma organização que não existe, recebe 404 not_found. Não concede associação a nenhum projeto. Somente sessões por cookie; uma credencial de agente é recusada.

Administradores da organização leem apenas nomes de projetos, proprietários, status e contagem de telas; isso não concede acesso ao projeto. Um administrador lê o conteúdo de um projeto somente depois de entrar nele (POST .../projects/{project_id}/access) e gerencia as pessoas dele com as rotas de proprietário e de membros abaixo.

Os revendedores ativos cuja organização a pessoa conectada administra (admin_user_ids), ordenados por nome; vazio para todas as outras pessoas. Somente sessões por cookie. Um revendedor é uma organização que a equipe tornou revendedora ou que um de seus admins registrou (POST /api/resellers); seus admins gerenciam as organizações dos clientes dele (docs/resellers.md).

Um admin de uma organização a torna revendedora imediatamente. O chamador deve ser uma pessoa conectada com endereço de e-mail verificado (somente sessões por cookie; agentes e clientes de serviço nunca têm autoridade de revendedor) e admin da organização indicada por organization_id; qualquer outra pessoa recebe 404 not_found.

O revendedor começa com 2000 pontos-base do preço de tabela (20%), em vigor desde agora, e fica aguardando análise; ele cadastra até 10 clientes atuais (customer_limit) até que o screenRIG o analise. A organização deve estar ativa, não ser já um revendedor, não ser cliente de um revendedor e não estar no plano staff ou promo (409 reseller_conflict, o detalhe informa o motivo).

Acrescenta reseller.enrolled à auditoria da organização.

Um revendedor que o chamador administra, com a sua margem. Qualquer outra pessoa recebe 404 not_found.

Os clientes atuais do revendedor (organizações delegadas a ele), ordenados por nome, com plano, contagens e bytes armazenados. Somente admins do revendedor; qualquer outra pessoa recebe 404 not_found.

Cria uma organização cliente delegada ao revendedor desde a sua criação, no plano Standard, tendo como único admin o admin do revendedor que faz a chamada. A organização principal do chamador não muda. Os próprios admins da organização podem encerrar a delegação depois (DELETE /api/organizations/{org_id}/reseller).

Acrescenta organization.created e reseller.customer_started à auditoria da organização. Um revendedor aguardando análise (review_state pending) cadastra até customer_limit clientes atuais; acima disso, a resposta é 409 reseller_conflict.

Um cliente atual do revendedor. Somente admins do revendedor; uma organização que não é cliente atual responde 404 not_found.

Define o plano de um cliente atual, pelo qual o revendedor paga. standard remove o plano; plus e premium são sempre permitidos, education somente para uma organização elegível para educação. Enterprise, staff e promo são atribuídos pela equipe.

Um upgrade vale de imediato; um downgrade ou uma remoção, no próximo limite mensal UTC, como nas mudanças de plano de uma organização (docs/billing-rollup.md). Acrescenta reseller.customer_plan à auditoria da organização.

Os projetos ativos de um cliente atual, com nomes, status, contagem de telas e se o chamador já é membro. Listar não concede acesso a projetos; POST .../access entra em um deles.

Torna o admin do revendedor que faz a chamada um membro pleno do projeto de um cliente atual (can_approve, sem escopos, origem reseller_admin), como faz a entrada de um admin da organização, para que possa abri-lo com PUT /api/session/project. Quem já é membro recebe o projeto inalterado.

Acrescenta member.added_by_reseller ao projeto e reseller.project_joined à auditoria da organização, e envia um e-mail ao proprietário do projeto. A associação permanece até ser removida; encerrar a delegação não a remove.

O que o revendedor deve por um mês UTC. Uma linha por cliente delegado em qualquer momento do mês, com a parte das cobranças de uso, na parte delegada do mês, que o crédito do próprio cliente não cobriu (ao preço de tabela e ao preço do revendedor), e o preço anual do plano dele.

O preço do revendedor é o de tabela menos a margem em vigor na data mais recente entre o início do mês e a (re)criação do revendedor. Somente admins do revendedor.

Um admin da organização encerra de imediato a delegação ao seu revendedor. A partir daí a organização paga por si mesma; seu plano, seus projetos e seus membros permanecem como estão, inclusive as associações que os admins do revendedor têm. O excedente que a carteira dela acumulou durante a delegação, pelo qual o revendedor é cobrado, é baixado na mesma alteração.

Acrescenta reseller.customer_ended à auditoria da organização. Uma organização sem revendedor responde 404 not_found.

Projetos em outros locais cujos proprietários têm um e-mail verificado no domínio verificado exato. Endereços de contato e subdomínios não correspondem, e administradores não podem puxar projetos.

Abra um desafio DNS TXT de 7 dias para um domínio, substituindo o desafio pendente desse domínio; os outros domínios da organização permanecem inalterados. Coloque seu valor exato no nome DNS retornado e mantenha-o lá. Uma organização mantém no máximo 20 domínios, verificados e pendentes juntos (resource_conflict). Um domínio mantido por outra organização é resource_conflict.

Um domínio que esta organização já possui pode ser comprovado novamente, o que registra o novo valor para a verificação diária de DNS.

Verifique um desafio não expirado contra DNS e adicione seu domínio à organização, além dos domínios que ela já possui. Cada domínio exato pertence a uma organização. Uma prova rotacionada durante a verificação é recusada. Mantenha o registro TXT no lugar; uma verificação diária remove um domínio cujo registro permanece ausente por sete dias.

Uma vez que a reivindicação é confirmada, e em segundo plano após esta resposta, cada projeto cujo proprietário é uma pessoa verificada exatamente no domínio e que está sozinho na organização pessoal desse proprietário é movido para esta organização (renomeado para "<name> (<owner>)" em caso de conflito de nome).

Projetos em qualquer outra organização, projetos com plano pago pelo cliente próprio, e projetos que seu proprietário ou equipe transferiu para fora de uma organização de domínio permanecem onde estão; um projeto que os limites da organização recusam é tentado novamente um dia depois. O posicionamento não concede acesso.

Um administrador designado lê os administradores da organização, os candidatos que podem se tornar um (proprietários verificados e ativos de seus projetos ao vivo que ainda não são administradores) e a revisão da organização. Qualquer outro é recusado como nas outras rotas de administrador da organização. Apenas pessoas; agentes e credenciais portadoras não têm rota de administrador.

Um administrador designado substitui os administradores da organização. If-Match carrega a revisão da organização; uma desatualizada é revision_conflict com current_revision. O conjunto nomeia de 1 a 20 pessoas, cada uma um administrador atual ou um candidato, caso contrário invalid_request; um administrador remove a si mesmo somente enquanto outro administrador permanecer.

A alteração incrementa a revisão, é registrada na auditoria da organização, não concede associação ao projeto e retorna a mesma forma que GET. Apenas pessoas; agentes e credenciais bearer não têm rota admin.

Um administrador designado lê as pessoas da organização. Somente leitura. projects lista os projetos ativos da organização, ordenados por nome, no máximo 500. people é a união dos membros da organização (member true), das associações ativas nesses projetos (associações suspensas ficam de fora) e dos administradores designados.

A ordem é administradores primeiro, depois membros da organização, depois pessoas externas (as que não são membros da organização), cada grupo por nome de exibição e depois por e-mail.

Cada pessoa traz sua função em cada projeto (owner ou member), se pode aprovar revisões nele (can_approve) e se está limitada a telas ou uploads (limited), se é administrador, se é membro da organização (member), se é gerenciada pela organização (managed) e, para uma pessoa externa, se a política de convidados atual não a admitiria (outside_guest_policy).

Um administrador ou membro da organização que não está em nenhum projeto aparece com a lista projects vazia. email fica vazio para uma pessoa cujo endereço não foi verificado. Pessoas e agentes desativados nunca aparecem. No máximo 500 pessoas são retornadas, administradores sempre entre elas; truncated é verdadeiro quando pessoas, projetos ou associações foram omitidos.

Qualquer outra pessoa é recusada como nas demais rotas de administração da organização. Somente pessoas; agentes e credenciais bearer não têm rota.

Um administrador designado lista os convites de administrador da organização por id, 50 de cada vez, após expirar os que passaram do tempo. Endereços dos destinatários são visíveis para os administradores da organização, que os forneceram. Tokens e URLs de credenciais nunca são listados. Apenas pessoas; agentes e credenciais portadoras não têm rota de administrador.

Um administrador designado convida pessoas por e-mail para se tornarem administradores. Aceitar adiciona a pessoa aos administradores da organização e cria seu login se não tiver; não concede associação ao projeto. No máximo 20 administradores contando convites pendentes (organization_admin_limit); um endereço cuja pessoa já administra a organização é invalid_request.

Convites por e-mail expiram após sete dias; um convite pendente para o mesmo endereço é reutilizado. Os nomes da organização e do convidador devem ser adequados para e-mail. Apenas pessoas; agentes e credenciais de portador não têm rota de administrador.

Um administrador designado revoga um convite de administrador pendente e libera sua vaga de administrador. Um convite já revogado retorna 204; um aceito retorna invitation_consumed; um id que a organização não possui é not_found. Apenas pessoas; agentes e credenciais portadoras não têm rota de administrador.

Um administrador designado lista os convites de membro da organização por id, 50 de cada vez, após expirar os que passaram do tempo. Endereços dos destinatários são visíveis para os administradores da organização, que os forneceram. Tokens e URLs de credenciais nunca são listados. Somente pessoas; agentes e credenciais bearer não têm rota de administrador.

Um administrador designado convida pessoas por e-mail para entrarem na organização como membros. Aceitar define a organização principal da pessoa como esta, substituindo qualquer organização principal anterior, e cria seu login se não tiver; não concede associação ao projeto.

Um endereço cuja pessoa já é membro da organização é invalid_request; um cuja pessoa é gerenciada por outra organização é managed_elsewhere. Convites por e-mail expiram após sete dias; um convite pendente para o mesmo endereço é reutilizado. Os nomes da organização e do convidador devem ser adequados para e-mail.

Aceitar um convite para a organização da equipe (plan_id staff) também torna a pessoa membro da equipe. Por isso, somente a equipe pode enviar esses convites, a um endereço por solicitação com uma comprovação staff_grant vinculada a ele (reauthentication_required sem ela). Apenas pessoas; agentes e credenciais bearer não têm rota de administração.

Um administrador designado revoga um convite de membro pendente. Um convite já revogado retorna 204; um aceito retorna invitation_consumed; um id que a organização não possui é not_found. Somente pessoas; agentes e credenciais bearer não têm rota de administrador.

Um administrador designado remove um membro da organização.

Em uma transação, a organização principal da pessoa é limpa e suas associações em todos os projetos ativos da organização terminam, cada uma como a remoção dela desse projeto faria (os convites por e-mail pendentes para ele são revogados e as sessões dela deixam de resolvê-lo); as associações em projetos de outras organizações permanecem intactas, e nenhuma outra organização muda.

A alteração é registrada na auditoria da organização.

Uma pessoa que um provedor de identidade gerencia (login único ou SCIM) é managed_member; um administrador designado é organization_admin_member (remova primeiro a vaga de administrador com PUT /api/organizations/{org_id}/admins); uma pessoa que é proprietária de qualquer projeto ativo da organização é member_owns_projects e o detalhe lista os nomes dos projetos (transfira primeiro esses projetos, nada é removido); uma pessoa que não é membro da organização, inclusive uma já removida, é not_found.

Somente pessoas; agentes e credenciais bearer não têm rota de administrador.

Um administrador designado define quem a organização admite em seus projetos como convidados, isto é, pessoas cuja organização principal é outra ou que não têm nenhuma. mode allow (o padrão) admite todos os convidados, domains admite um convidado cujo endereço de e-mail verificado está em um dos domains, e none não admite nenhum convidado. domains lista de 1 a 20 nomes DNS distintos em minúsculas, obrigatório para mode domains e omitido nos demais casos; qualquer outra forma é invalid_request.

A política substitui a anterior, incrementa a revisão da organização, é registrada na auditoria da organização e responde com a política em vigor. Ela é verificada quando a organização concede a um convidado uma associação a um projeto, por convite de membro do projeto (criar e aceitar) e por vínculo de grupo SCIM, e recusa com guest_not_allowed.

A equipe e os próprios administradores da organização estão isentos, agentes não são verificados, e membros da organização nunca são convidados. Restringir a política não remove ninguém; outside_policy conta as pessoas externas já presentes nos projetos ativos da organização que a nova política não admitiria, e GET /api/organizations/{org_id}/people sinaliza cada uma delas (outside_guest_policy).

Somente pessoas; agentes e credenciais bearer não têm rota de administrador.

Um administrador designado define ou remove o projeto Biblioteca da organização. project_id indica um dos projetos ativos da organização, ou null para remover.

Todos os outros projetos da organização passam então a ler as mídias, as pastas de mídia e as playlists da Biblioteca (library=true em GET /api/media, /api/media-folders e /api/playlists, e por ID) e as usam somente para leitura: referências de mídia nas páginas, seletores by:folder que citam uma pasta da Biblioteca (os seletores de tag e de todos nunca alcançam a Biblioteca), cronogramas e pilhas das telas, e from_template. Somente os membros da própria Biblioteca as alteram.

O projeto Biblioteca não tem telas: um projeto com telas resulta em library_no_screens, e a Biblioteca não admite nenhuma depois. Definir uma Biblioteca exige o recurso de plano library (Premium, Education, Enterprise; caso contrário, feature_not_in_plan); removê-la nunca exige, e uma Biblioteca mantida após um downgrade continua sendo servida.

Se a Biblioteca for removida ou substituída, as playlists dos projetos membros que citam seus itens deixam de resolvê-los na próxima gravação, e as telas deixam de receber as mídias dela. Um projeto que é a Biblioteca e é excluído ou movido para fora da organização a remove.

Responde com a visão da organização, é registrada na auditoria da organização (organization.library_changed) e incrementa a revisão. Somente pessoas.

Um administrador designado define o acesso de muitas pessoas a muitos dos projetos ativos da organização em uma única requisição, sem entrar em nenhum deles.

Cada mudança, de 1 a 500, nomeia um projeto, uma pessoa e um acesso, sem repetir nenhum par (project_id, user_id). member torna a pessoa um membro do projeto que não pode aprovar revisões (adicionada quando não é membro; um aprovador perde a aprovação), approver um membro que pode aprovar (adicionado quando não é membro), e none nenhum membro (removida quando é membro).

Tudo é aplicado em ordem em uma única transação, e uma recusa desfaz o lote inteiro; cada recusa aponta changes[i] (o projeto ou a pessoa) ou changes[i].access em errors[].field.

Um projeto que não é um projeto ativo desta organização é not_found; uma pessoa que não é uma pessoa ativa (um agente, uma pessoa desativada, um id desconhecido) ou que é da equipe, uma associação suspensa, e uma pessoa adicionada que não é uma das pessoas da organização (seus administradores, seus membros da organização e os membros ativos de seus outros projetos ativos; qualquer outra pessoa entra por um convite) são invalid_request; o proprietário nunca é definido como member ou none (owner_cannot_leave); um uploader nunca aprova (resource_conflict, como PUT /api/members/{user_id}/approver responde); remover o próprio administrador é proibido (um administrador sai por DELETE /api/members/{user_id}); e uma pessoa adicionada é admitida como um convite a admite, ou seja, os membros da organização e os administradores da organização sempre, e uma pessoa externa somente onde a política de convidados a admite agora (guest_not_allowed).

O limite de 200 membros do projeto e o limite de membros do plano dele se aplicam ao que é adicionado (member_limit_reached). A resposta repete cada mudança na ordem da requisição; changed é false para uma cujo acesso já estava em vigor, que não grava nem registra nada.

Cada mudança é registrada na auditoria da organização (organization.project_member_added, organization.project_member_approver_changed ou organization.project_member_removed) e nos eventos do projeto (member.added_by_organization_admin, project.member_approver_changed ou member.removed, marcados como do administrador da organização), e o proprietário de cada projeto recebe um e-mail uma única vez por lote, a menos que tenha sido ele a fazer a mudança.

Somente pessoas; agentes e credenciais bearer não têm rota de administrador.

Um administrador designado entra em um dos projetos ativos da organização como membro sem escopo de telas ou de upload que pode aprovar revisões. Entrar é o que dá ao administrador o conteúdo do projeto, que as rotas da organização nunca mostram.

Um administrador que já é membro sem escopo e que pode aprovar recebe 200 com joined false e nada muda; um membro com escopo de telas ou de upload, ou que não pode aprovar, torna-se um membro sem escopo que pode aprovar, registrado como uma entrada.

O limite de 200 membros do projeto se aplica (member_limit_reached); a política de convidados da organização nunca se aplica aos próprios administradores. A entrada é registrada na auditoria da organização como organization.project_joined e nos eventos do projeto como member.added_by_organization_admin, e o proprietário do projeto recebe um e-mail.

Um projeto que a organização não possui, ou que foi excluído, é not_found. Somente pessoas; agentes e credenciais bearer não têm rota de administrador.

Um administrador designado torna uma pessoa o proprietário de um dos projetos ativos da organização sem entrar nele, a partir de quem é o proprietário atual, inclusive um proprietário com a conta desativada.

O novo proprietário é uma pessoa verificada e ativa que é membro do projeto ou membro da organização (um membro da organização que não é membro do projeto é adicionado primeiro como membro sem escopo de telas ou de upload que pode aprovar revisões; a política de convidados não se aplica a um membro da organização); qualquer outra pessoa é invalid_request em user_id.

Um administrador se define como proprietário somente depois de entrar no projeto (POST /api/organizations/{org_id}/projects/{project_id}/access), e quem não é membro sem escopo de telas ou de upload que pode aprovar é invalid_request em user_id.

O efeito é o da transferência feita pelo próprio proprietário, então o escopo de telas e o escopo de upload do novo proprietário são limpos e as responsabilidades legadas do projeto passam a ser vinculadas a ele. Indicar o proprietário atual não altera nada. A alteração é registrada na auditoria da organização como organization.project_owner_changed, e o proprietário anterior e o novo recebem um e-mail.

O limite de 200 membros do projeto se aplica a um membro da organização adicionado (member_limit_reached). Um projeto que a organização não possui, ou que foi excluído, é not_found. Somente pessoas; agentes e credenciais bearer não têm rota de administrador.

Um administrador designado remove um membro de um dos projetos ativos da organização sem entrar nele. Tem o efeito da remoção feita pelo proprietário (DELETE /api/members/{user_id}). A associação termina, os convites por e-mail pendentes da pessoa para o projeto são revogados, as sessões dela deixam de resolver o projeto e as associações de agentes permanecem.

O proprietário nunca é removido (owner_cannot_leave; transfira primeiro a propriedade com PUT /api/organizations/{org_id}/projects/{project_id}/owner). Uma pessoa que não é membro do projeto, inclusive uma já removida, e um projeto que a organização não possui ou que foi excluído são not_found.

A remoção é registrada na auditoria da organização como organization.project_member_removed e nos eventos do projeto como member.removed com removed_by_organization_admin true. Somente pessoas; agentes e credenciais bearer não têm rota de administrador.

Remover um domínio, verificado ou pendente, e deixar os outros domínios da organização. A colocação futura e a descoberta para ele param, e outra organização pode verificá-lo. Projetos já na organização permanecem. Um domínio que a organização não possui nem está provando é not_found.

Enquanto a organização exige login único, um domínio verificado é resource_conflict; desativar Exigir login único entra em vigor após 72 horas, e o domínio pode ser removido nessa ocasião.

Define se um membro pode aprovar: decidir revisões e conceder aos agentes acesso Gerenciar. Um membro que não pode aprovar tem seus agentes mantidos em Propose. Somente o proprietário do projeto ou um membro que administra a organização do projeto (forbidden caso contrário); a própria linha do proprietário é fixa (resource_conflict); um não-membro é not_found.

Acrescenta project.member_approver_changed (detalhes user_id, can_approve).

Limita um membro a pastas de telas (cada uma com todas as pastas dentro dela) e telas, ou substitui o escopo de um (docs/screen-scope.md).

Em uma transação, também encerra os agentes que a pessoa trouxe ao projeto (agent.disconnected, como removê-los faria) e acrescenta project.member_screen_scope_changed (detalhes user_id, screen_scope, previous, changed_by_user_id). O escopo é lido na próxima requisição do membro: a mudança aparece no próximo GET /api/session dele, sem entrar de novo.

Somente o proprietário do projeto ou um membro que administra a organização do projeto (forbidden caso contrário); a própria linha do proprietário, um uploader (um membro com escopo é limitado a telas, um uploader a conteúdo) e um membro que aprova revisões com telas avulsas no escopo são resource_conflict; um não membro é not_found; um id que não é uma pasta de telas nem uma tela existente do projeto é invalid_request em screen_scope.folder_ids[i] ou screen_scope.screen_ids[i].

Um membro com escopo que aprova revisões aprova apenas dentro do escopo; um que não pode aprovar lê e executa comandos, mas só altera o que é reproduzido por meio de aprovadores (approver_required).

Um escopo também é recusado com resource_conflict enquanto a pessoa, ou um agente que a pessoa trouxe, tem um cliente de serviço ativo do projeto: o detalhe nomeia até cinco clientes como ID (nome) e conta o restante, e nada é gravado.

Limitar uma pessoa a telas é o recurso de escopo de telas, que o plano Enterprise inclui; um projeto cujo plano não o inclui é recusado com feature_not_in_plan (402). Um escopo definido continua limitando a pessoa até ser limpo (DELETE), o que todo plano pode fazer.

Devolve a um membro com escopo as telas do projeto inteiro. Somente o proprietário do projeto ou um membro que administra a organização do projeto; um membro sem escopo fica como está. Acrescenta project.member_screen_scope_changed com screen_scope null.

Limita a associação de um agente ao projeto da sessão a pastas de telas e telas, ou substitui o seu escopo (docs/screen-scope.md). O alcance do agente é este escopo restringido pelo da pessoa responsável por ele, então uma pessoa com escopo nunca age por meio de um agente mais amplo do que ela.

Somente o proprietário do projeto ou um membro que administra a organização do projeto (forbidden caso contrário); um agente que não é membro do projeto é not_found. Acrescenta agent.screen_scope_changed (detalhes agent_id, screen_scope, previous, changed_by_user_id).

O escopo de um agente vale para a próxima requisição dele na instância que o gravou e em até dois segundos nas outras. Um escopo é recusado com resource_conflict enquanto o agente tem um cliente de serviço ativo do projeto: o detalhe nomeia até cinco clientes como ID (nome) e conta o restante, e nada é gravado.

Limitar um agente a telas é o recurso de escopo de telas, que o plano Enterprise inclui; um projeto cujo plano não o inclui é recusado com feature_not_in_plan (402). Um escopo definido continua limitando o agente até ser limpo (DELETE), o que todo plano pode fazer.

Remove o escopo da associação de um agente ao projeto da sessão. Somente o proprietário do projeto ou um membro que administra a organização do projeto. Acrescenta agent.screen_scope_changed com screen_scope null.

Transforma um membro em uploader ou substitui o escopo de um (docs/uploaders.md): as playlists cujas páginas ele altera e as pastas de mídia para as quais envia.

Em uma única transação, também impede que aprovem revisões, encerra os agentes que trouxeram ao projeto (agent.disconnected, como a remoção faria) e acrescenta project.member_upload_scope_changed (detalhes user_id, upload_scope, changed_by_user_id).

O escopo é lido na próxima requisição do membro: a mudança aparece no próximo GET /api/session, sem entrar novamente.

Somente o proprietário do projeto ou um membro que administra a organização do projeto (caso contrário, forbidden); a própria linha do proprietário é resource_conflict; um não membro é not_found; um id que não é uma playlist ou pasta de mídia ativa do projeto é invalid_request em upload_scope.playlist_ids[i] ou upload_scope.folder_ids[i]. access propose (o padrão) envia as alterações do uploader para revisão; manage as publica.

Um membro limitado a telas é resource_conflict: remova esse escopo primeiro (DELETE /api/members/{user_id}/screen-scope).

Torna um uploader novamente um membro completo, que não aprova revisões (ative isso com setDashboardMemberApprover). Somente o proprietário do projeto ou um membro que administra a organização do projeto; um membro que não é uploader permanece como está. Acrescenta project.member_upload_scope_changed com upload_scope null.