API de Dashboard

Inspecciona una invitación sin consumirla. Nunca informa el estado de registro o verificación, salvo que un restablecimiento de inicio de sesión informa replaces_unverified_account. Una invitación organization_admin u organization_member informa el nombre de la organización y ningún proyecto.

Inicia una ceremonia de registro de cinco minutos vinculada al resumen y modo de la invitación. La creación de enlace create_login requiere una cookie __Host-screenrig-signup verificada y usa su nombre.

La creación de correo electrónico create_login vincula el nombre para mostrar suministrado; el restablecimiento vincula a la persona objetivo, salvo que un restablecimiento de una dirección no verificada registra la passkey para la persona nueva que crea, nombrada según el nombre para mostrar suministrado o, si falta, a partir de la dirección.

Ese restablecimiento requiere replace_unverified_account true (la inspección informa replaces_unverified_account) y, de lo contrario, responde 409 unverified_account_replacement.

Inicia un registro de enlace vinculado al navegador y revoca registros anteriores para esta invitación. El desafío de verificación está vinculado a este registro. La autenticación de desarrollo verifica el registro inmediatamente sin correo.

Devuelve el registro en vivo perteneciente a este navegador. Una cookie de registro faltante, revocada, consumida o expirada devuelve invitation_invalid.

Acepta una invitación de forma transaccional y crea una nueva sesión de persona, eliminando la sesión antigua si está presente.

El enlace create_login requiere la cookie __Host-screenrig-signup verificada para esta invitación. signed_in requiere una sesión del dashboard y un inicio de sesión reciente o una prueba reciente; la entrega por correo electrónico requiere un correo electrónico verificado que coincida, o la dirección no verificada de la persona con sesión iniciada, que la aceptación verifica.

Una dirección que ya tiene una persona activa, verificada o no, devuelve resource_conflict para create_login. Un restablecimiento inicia sesión a la persona que tiene una dirección verificada.

Un restablecimiento de una dirección no verificada requiere replace_unverified_account true (la inspección informa replaces_unverified_account) y, de lo contrario, responde 409 unverified_account_replacement y no consume nada; con ello, el restablecimiento crea una persona nueva y verificada con la credencial que registra, nombrada según display_name o, si falta, a partir de la dirección, con una organización y un proyecto nuevos, e inicia la sesión de esa persona; la persona no verificada se elimina (sus sesiones, passkeys y agentes terminan) y los proyectos y las organizaciones que creó quedan, sin ella y sin coincidir ya con la dirección como su contacto, de modo que ningún restablecimiento posterior les reenvía una invitación de inscripción.

La respuesta nombra el proyecto nuevo. Una sesión cuya verificación de correo electrónico es obligatoria (email_verification_required en GET /api/session) acepta solo una invitación enviada por correo electrónico que nombre su propia dirección y recibe 403 email_verification_required para cualquier otra.

Una invitación organization_admin añade a la persona a los administradores de la organización y no abre ningún proyecto; devuelve organization_admin_limit cuando la organización ya tiene 20 administradores y sigue pendiente, y resource_conflict cuando la organización fue eliminada.

Una invitación organization_member establece la organización principal de la persona como la organización que invita, sustituyendo cualquier otra anterior, y no concede membresía de proyecto; devuelve managed_elsewhere (409) cuando otra organización administra a la persona, y resource_conflict cuando la organización fue eliminada.

Una invitación organization_admin establece la organización principal solo para una persona que no tiene ninguna. Una invitación project_member vuelve a comprobar la política de invitados de la organización y devuelve guest_not_allowed (403) cuando la persona sería un invitado externo que la política rechaza; una invitación a un proyecto nunca cambia la organización principal de nadie. Una invitación rechazada permanece pendiente.

Inicia una ceremonia de registro de cinco minutos para un registro de autoservicio, vinculada a la dirección de correo electrónico normalizada y al nombre para mostrar. No crea nada y no envía ningún correo.

Una dirección que tiene una persona activa, verificada o no, devuelve 409 account_exists; una dirección de un dominio cuya organización inicia sesión mediante un proveedor de identidad devuelve 403 sso_required; una dirección o un nombre no válidos devuelven 400 invalid_request con errores de campo. Un servidor que ejecuta la autenticación de desarrollo del dashboard devuelve passkeys_disabled.

Limitado por dirección cliente.

Crea una cuenta de autoservicio e inicia sesión en este navegador.

Una transacción crea a la persona con una dirección de correo electrónico no verificada y un plazo de verificación 72 horas después, registra la passkey de la ceremonia que inició POST /api/signups/passkey-options, crea la organización y el proyecto de la persona como los crea la inscripción de agente, convierte a la persona en propietaria del proyecto, almacena la elección de correo de marketing y pone en cola el correo de verificación (propósito account_email).

El visitante del sitio web que abrió la página se vincula a la cuenta y el registro se cuenta como signed_up. La respuesta establece la cookie de sesión del dashboard. Los rechazos son los de POST /api/signups/passkey-options; una ceremonia usada, expirada o que no coincide devuelve 400 invalid_request. Limitado por dirección cliente y por dirección de correo electrónico.

Cambia a uno de los proyectos de la persona y actualiza su última hora de uso. Un miembro del personal también puede cambiar a un proyecto que supervisa; esa sesión reporta shadow true, es solo lectura y no actualiza la última hora de uso. Cualquier otro proyecto devuelve not_found.

Lista miembros del proyecto actual sin sus direcciones de correo electrónico privadas.

Todos los miembros tienen la misma autoridad excepto en la gestión de miembros (eliminación, aprobador, alcances, propiedad), que corresponde al propietario y a un administrador de la organización del proyecto que es miembro. owner marca al propietario del proyecto, external marca a un invitado (la organización principal del miembro no es la organización del proyecto), y viewer_user_id y viewer_is_owner describen a la persona conectada.

Elimina un miembro del proyecto actual. El propietario del proyecto elimina a cualquier otro miembro, y también lo hace un administrador de la organización del proyecto que es miembro; cualquier miembro se elimina a sí mismo para salir. El propietario nunca se elimina ni sale (owner_cannot_leave; primero transfiera la propiedad). Se rechaza con owner_required que un miembro elimine a otro.

Una persona que no es miembro, incluso una ya eliminada, es not_found. En una transacción, la membresía termina, se revocan las invitaciones por correo electrónico pendientes de esa persona al proyecto, y se añade el evento member.removed al proyecto (detalles user_id, removed_by_user_id, left).

Las sesiones de la persona dejan de resolver el proyecto en su siguiente solicitud y vuelven al estado posterior a la eliminación del proyecto. Las membresías de agentes son independientes y permanentes. Solo personas; sin ruta portadora.

La actividad de una persona en el proyecto actual, la más reciente primero: sus inicios de sesión (y los inicios de sesión rechazados que nombran su dirección o passkey), cierres de sesión, cambios al proyecto, cambios de credenciales, pruebas de reautenticación y cada cambio que hizo a través del panel, incluidos los rechazados y fallidos. Las lecturas nunca se registran.

Las solicitudes de agentes y CLI están en sus agentes (listDashboardAgentEvents). La sombra de un miembro del personal del proyecto no registra nada; un cambio realizado bajo un contrato de escritura aprobado por el personal es una fila de ese miembro con origen en el personal.

La persona misma, el propietario del proyecto, un administrador de la organización del proyecto y un miembro del personal que supervisa el proyecto pueden leerlo. Cualquier otro recibe not_found, al igual que una persona que no es miembro ni tiene filas aquí, por lo que la respuesta nunca indica quién pertenece; las filas de un exmiembro permanecen legibles.

El proyecto es de la sesión, nunca de la solicitud, y solo se devuelven filas de ese proyecto.

Cada valor es derivado del servidor: la acción de la ruta que el servidor coincidió (o una acción de cuenta nombrada como session.sign_in o passkey.add), el recurso del primer valor de ruta cuando es un identificador emitido por el servidor, status, problem_code y error del registro de problemas, el cliente analizado del User-Agent y la pista de plataforma (el User-Agent bruto no se guarda).

No se almacena cuerpo de solicitud, contraseña, token ni cookie. client_ip y correo electrónico se muestran tal como se registraron.

Las claves de paginación son (at, id) descendentes. Pase next_cursor como after para continuar; es null al final. Una fila escrita mientras tanto solo aparece antes de la primera página y la retención elimina las filas más antiguas, por lo que un cursor nunca repite ni salta una fila sobreviviente. Un cursor o filtro malformado se rechaza con invalid_request; un límite fuera de 1-100 es el predeterminado.

Las filas expiran según la ventana de retención de eventos del proyecto en el momento en que fueron escritas. recorded_since es el tiempo de la fila más antigua sobreviviente del proyecto, o, antes de cualquiera, cuando este servidor comenzó a grabar; nada anterior a eso se reconstruye.

Devuelve el perfil y los conteos de credenciales de la persona conectada.

Marca para eliminación a la persona conectada. Protegido por prueba: el cuerpo lleva una prueba de inicio de sesión fresca verificada contra una reautenticación vinculada a esta sesión con tipo account_delete y subject_id igual al id de usuario de la persona conectada (inícielo con POST /api/me/reauthentications). Sin una reautenticación actual la respuesta es reauthentication_required.

Al tener éxito, la respuesta es 204, la cookie de sesión del dashboard se borra y la caché HTTP del navegador para el origen del dashboard se limpia como al cerrar sesión.

Inicia el paso de clave de acceso vinculado a la sesión, tipo y sujeto. Una persona sin clave de acceso recibe resource_conflict y usa una prueba de contraseña.

Establece o reemplaza la contraseña de la persona tras una prueba reciente. La primera contraseña requiere prueba de passkey; el reemplazo acepta la contraseña actual o un passkey. Revoca otras sesiones y encola un aviso de cambio de inicio de sesión.

Una persona cuyo correo electrónico no está verificado, como un registro de autoservicio antes de verificarlo, no puede establecer una contraseña y recibe 403 email_verification_required.

Lista las passkeys de la persona con lo que un cliente necesita para mantener sincronizado con ellas el administrador de contraseñas del navegador (la API Signal de WebAuthn). La lista incluye el ID de la parte confiable y el identificador de usuario (user handle) con los que están registradas las passkeys, y cada passkey incluye su ID de credencial y el proveedor que informó su autenticador.

Verifica prueba reciente e inicia un registro vinculado a la sesión y persona. Las passkeys están deshabilitadas bajo autenticación en desarrollo.

Almacena la nueva passkey, revoca las demás sesiones de la persona y pone en cola un aviso de cambio de inicio de sesión. Una passkey enviada sin nombre recibe el nombre de su proveedor, o Passkey cuando su autenticador no informó ninguno que la lista conozca.

Renombra un passkey propiedad de la persona conectada.

Elimina un passkey tras prueba reciente y envía una notificación de cambio de inicio de sesión. Quitar el último método de inicio de sesión devuelve last_credential. Una persona cuyo cuenta requiere passkey (todo el personal) no puede eliminar su último passkey; eso devuelve 409 resource_conflict.

Devuelve el estado del correo electrónico verificado y pendiente de la persona. Una persona que se registró por sí misma tiene una dirección no verificada hasta que abre el enlace enviado a ella; email_verified es false y verify_by es el plazo, después del cual la sesión solo puede usar las rutas que verifican o cambian la dirección (email_verification_required en GET /api/session).

Solicita un cambio de correo electrónico tras una prueba reciente. La dirección verificada sigue vigente mientras la verificación está pendiente. Una dirección que tiene cualquier otra persona activa, verificada o no, devuelve user_email_conflict. La dirección anterior recibe una advertencia, no un enlace para deshacer.

Una persona cuya dirección no está verificada la cambia de la misma manera; verificar la nueva dirección la convierte en la dirección verificada de la persona y borra verify_by.

Pone en cola un nuevo enlace de verificación. Mientras un cambio de correo electrónico espera verificación (pending_email en GET /api/me/email), es el enlace de ese cambio, enviado a la dirección pendiente; de lo contrario es un enlace account_email para la dirección actual no verificada de la persona. Dentro de los diez minutos posteriores al último enlace de su tipo no pone nada en cola y aun así responde 202.

Una persona cuya dirección está verificada y que no tiene ningún cambio pendiente devuelve 409 resource_conflict.

Reemplaza las respuestas que la persona dio tras registrarse por el cuerpo, que contiene todas las respuestas hasta el momento; un miembro omitido, o null, queda sin responder. Cada miembro tiene un conjunto de valores cerrado, y un valor fuera de él devuelve 400 invalid_request con un error de campo.

El perfil se conserva con la persona y se muestra al personal de screenRIG junto con la organización en la que se registró la persona.

Dónde está colocada una aplicación (app web) del proyecto de la sesión, calculado en una sola pasada sobre las listas de reproducción del proyecto y una lectura de las pantallas que las contienen. placements son las primitivas de aplicación cuya aplicación propietaria almacenada es esta aplicación, en orden de lista de reproducción (el del listado de listas de reproducción), de página y de primitiva; una lista de reproducción que la coloca dos veces tiene dos. release indica cómo está cada versión fijada respecto de latest_ready_release de la aplicación: latest, older, o unknown mientras la aplicación no tiene ninguno. screens son las pantallas pairing_pending y activas que tienen como predeterminada una lista de reproducción de una colocación, la programan, la usan en una toma de control o la muestran actualmente, las más recientes primero; las pantallas archivadas nunca cuentan, y una pantalla cuyo Player no puede mostrar apps web lleva applications_unsupported.

Un miembro o agente limitado a pantallas (screen_scope) ve solo sus pantallas, y screen_count cuenta solo esas. Esto no es lo que impide eliminar la aplicación, que son las concesiones de ejecución (el manifiesto de una pantalla que contiene una versión). Un id que el proyecto no tiene es not_found, como en getApplication. La respuesta es privada y no-store.

Dónde se usa un elemento multimedia listo del proyecto de la sesión, calculado en una sola pasada sobre las listas de reproducción del proyecto y una lectura de las pantallas que las contienen. playlists son las que nombran el archivo (los ids estáticos de una primitiva de imagen o video y un selector por id o ids, el respaldo de una transmisión, una cadena media:<id> en los params de una tarjeta, el logo de un stinger, una pista de banda sonora), luego las que lo alcanzan mediante selectores de etiqueta, carpeta o all, cada grupo en el orden del listado de listas de reproducción; una lista de reproducción es una entrada cuyo uses enumera cada forma, primero los tipos exactos.

Los selectores se evalúan tal como los resuelve el runtime: un filtro de etiquetas coincide con la etiqueta (tag) y las etiquetas (tags) del archivo, un selector de carpeta con los archivos que están directamente dentro de la carpeta, un selector all con todos los archivos del tipo, y un archivo pendiente por las últimas etiquetas y carpeta con las que se aprobó (un archivo nunca aprobado no es alcanzado por ninguno).

No se evalúan la rotación (batch_size, one_at_a_time), las ventanas de disponibilidad, el ajuste por aspecto ni la visibilidad de una página. screens son las pantallas pairing_pending y activas que tienen una de esas listas de reproducción como predeterminada, la programan, la usan en una toma de control o la muestran actualmente, las más recientes primero; las pantallas archivadas nunca cuentan.

Un miembro o agente limitado a pantallas (screen_scope) ve solo sus pantallas, y screen_count cuenta solo esas. Un id que el proyecto no tiene, o un elemento multimedia que no está listo, es not_found, como en getMedia. La respuesta es privada y no-store.

Devuelve un pequeño WebP con pérdida de una imagen lista propiedad del proyecto de la sesión, para que las cuadrículas del panel nunca decodifiquen originales. Hay un tamaño: cabe dentro de 512 x 512 con el aspecto mantenido y nunca se escala, y una imagen animada muestra su primer cuadro.

La primera solicitud la genera y almacena junto al original; solicitudes posteriores transmiten la copia almacenada, y eliminar el medio lo elimina junto con el original. El identificador de otro proyecto, video, audio y medios que no están listos devuelven not_found. No se acepta rango.

El ETag es fuerte y nombra el original y el generador de miniaturas, por lo que es el mismo en cada solicitud y host. La respuesta es privada, sin caché, y un If-None-Match que coincide, verificado después de que el medio se resuelve en el proyecto de la sesión, devuelve 304 sin leer la miniatura. Los bytes completados se registran como egreso dashboard_media.

Aplica las mismas reglas de propiedad, condicionales y de generación que getDashboardMediaThumbnail y devuelve sus encabezados sin el cuerpo. No se registra salida.

Vista previa segura para escáner. Nunca verifica una dirección, muta un usuario ni inicia sesión al visitante. Informa del propósito y el estado del enlace; un enlace account_email pendiente solo verifica para una solicitud que lleve la sesión del panel de la persona, por lo que una página pide el inicio de sesión antes de pedir la confirmación.

La confirmación humana explícita consume un desafío de verificación vinculado a un propósito. Los desafíos de registro por enlace requieren la cookie __Host-screenrig-signup correspondiente; los desafíos de cambio de correo electrónico están vinculados a un token, por lo que el enlace funciona en cualquier navegador.

Un desafío account_email (enviado por correo en el registro de autoservicio y por POST /api/me/email/verification, válido durante 30 días) se abre en cualquier navegador, pero solo verifica para una solicitud que lleve una sesión del panel activa de la persona a quien va dirigido el enlace, incluida una sesión que email_verification_required limita a esta ruta.

Sin sesión, o con la de otra persona, responde 200 sign_in_required, no verifica nada y deja el enlace utilizable. Un enlace account_email verificado marca la dirección de la persona como verificada y pone fin al plazo de verificación; responde superseded cuando otra persona verificó antes la misma dirección. La verificación nunca inicia sesión al visitante.

Inicia una ceremonia de afirmación WebAuthn sin nombre de usuario y devuelve las opciones de solicitud textualmente para navigator.credentials.get. No se requiere cookie, y no se publica lista allowCredentials, por lo que la ruta no revela nada sobre qué usuarios o credenciales existen. La ceremonia expira con DashboardCeremonyTTL de cinco minutos.

Cuando el servidor ejecuta la autenticación de desarrollo del dashboard, esta ruta devuelve passkeys_disabled.

Verifica una afirmación sin nombre de usuario y genera la cookie de sesión del dashboard para el usuario identificado por la credencial descubrible. Ninguna cookie autentica la solicitud. Una ceremonia desconocida, expirada o ya usada devuelve passkey_invalid, al igual que una afirmación que la parte confiable no puede verificar o un contador de firma que retrocede.

Una ceremonia válida cuyo identificador de credencial no está registrado a nombre de nadie (ninguna credencial almacenada lo tiene, de ninguna persona) devuelve en su lugar 401 passkey_unknown; esa respuesta es solo para ese caso, por lo que un cliente puede indicar al navegador que olvide la credencial (PublicKeyCredential.signalUnknownCredential) con esa respuesta y con ninguna otra.

El identificador de la credencial no es autorización por sí solo: lo es la aserción firmada. Una persona cuya dirección verificada pertenece a un dominio cuya organización exige el inicio de sesión único se rechaza con 403 sso_required, salvo que sea un administrador de emergencia de esa organización; ese inicio de sesión se audita.

Cuando el servidor ejecuta la autenticación de desarrollo del dashboard, esta ruta devuelve passkeys_disabled.

Inicia sesión a la persona identificada por correo electrónico verificado y contraseña. Un correo desconocido, la ausencia de contraseña y una contraseña incorrecta devuelven la misma respuesta no autorizada. Abre el proyecto usado por última vez si sigue siendo una membresía; de lo contrario, la membresía más reciente, o ningún proyecto.

Una dirección de un dominio cuya organización exige el inicio de sesión único se rechaza con 403 sso_required antes de buscar ninguna cuenta, de modo que la respuesta no depende de si una persona tiene la dirección; POST /api/sso/starts inicia sesión a esa persona mediante su proveedor de identidad.

El inicio de sesión con contraseña necesita un correo electrónico verificado, por lo que una persona que se registró por sí misma (POST /api/signups) inicia sesión con su passkey, y quien estableció una contraseña en una dirección no verificada sigue recibiendo la respuesta unauthorized. La autenticación de desarrollo usa este mismo flujo de contraseña.

Devuelve la sesión actual del dashboard. La cookie de sesión y la sesión del servidor establecen la autoridad; user_id es descriptivo. Una respuesta 401 significa que se requiere iniciar sesión.

El campo dev_auth está reservado para el desarrollo local y es falso en el servicio alojado. organization es la organización principal de la persona, ausente mientras no tiene ninguna; project.organization_admin indica que la persona administra la organización del proyecto actual.

Elimina la fila de sesión del lado del servidor y expira la cookie de sesión. No elimina al usuario ni elimina ninguna credencial. Es intrínsecamente idempotente y no requiere Idempotency-Key.

Un cierre de sesión exitoso también borra la caché HTTP del navegador para el origen del panel, eliminando los bytes privados, sin caché, multimedia, capturas de pantalla y revisión de anuncios que la sesión vio; una sesión que solo expira los deja hasta que el navegador los elimina.

Informa de un paso del recorrido de un navegador por los flujos de entrada del panel (registro, inicio de sesión, restablecimiento, invitación y adición de una passkey) para la lectura de incorporación del personal. Público: funciona con y sin sesión del panel.

El recorrido es el id aleatorio propio del navegador; el servidor también conserva la cookie de visitante del borde cuando la solicitud la lleva, y la persona y la organización cuando hay una sesión. Un recorrido es solo para el personal y conserva los valores reales que las personas ingresaron (direcciones, nombres, respuestas); nunca recibe una contraseña, un código ni un token.

Se conserva el primer valor de mode, source, utm_source, utm_medium, utm_campaign, click_kind, site_trail y site_cta; cada paso conserva la hora en que se registró por primera vez, y el value y el detail de un paso y el correo electrónico del recorrido (de email_submitted) son los más recientes. source solo se acepta con entry_viewed. question es obligatorio con los pasos question_* y se rechaza con cualquier otro. detail es un código de problema para un paso *_failed, el método de inicio de sesión para signed_in, o connected o skipped para signup_finished. email_verified, email_gate_reached, site_visited, site_cta_clicked y los hitos de la cuenta los escribe o los deriva el servidor y aquí se rechazan.

Solo se limitan las longitudes. Limitado por dirección cliente.

Lista todos los agentes pendientes, activos, revocados, cancelados y expirados del proyecto de la sesión con metadatos de instalación seguros, último uso, conteo de solicitudes autenticadas y créditos medidos directamente atribuibles. No se devuelve portador, bytes de clave de destinatario, sobre ni identificador de proyecto.

El historial de este agente, el más reciente primero, como UN registro por disparador. Contiene tanto lo que el agente solicitó como lo que cambió como resultado. Una solicitud que cambió algo es su evento de dominio, marcado con el comando que lo causó. Una solicitud que no cambió nada — rechazada, fallida o un éxito sin evento — es un evento agent.command.

No hay un endpoint separado de comandos; mostrar el mismo trigger en dos paneles era el defecto que esto reemplazó. Se incluyen eventos de ciclo de vida para este agente. La actividad solo de trabajador, player y dashboard nunca se infiere como actividad del agente. Dos solicitudes son dos triggers. Un reintento tras un rechazo es un segundo registro, nunca una reescritura del primero.

Las lecturas no se registran, porque no cambian nada y un agente de sondeo enterraría toda acción real. La inscripción anónima está excluida. Cada parte del sello de comando deriva de la ruta que este servidor coincidió o del registro de problemas.

No hay vector de argumentos, ni cuerpo de solicitud, ni encabezado, ni texto libre en ningún registro, por lo que no hay nada que redactar y ningún llamador puede escribir texto elegido en una superficie visible para el operador. Los identificadores de recursos aparecen porque un identificador nunca es autorización y ya se publica en eventos. Claves de paginación en secuencia, descendente.

Pase el next_cursor devuelto como after para continuar. next_cursor está vacío cuando la página es corta, que es el final del historial: un apéndice concurrente solo toma una secuencia más alta, y la retención elimina primero las secuencias más bajas, por lo que un cursor nunca duplica ni salta un registro sobreviviente. No se admite paginación por desplazamiento.

Cada parámetro de búsqueda es un predicado de coincidencia exacta o rango sobre un token escrito por el servidor. Un cursor o filtro malformado se rechaza con invalid_request. Un límite fuera de 1-200 se ajusta al valor predeterminado en lugar de rechazarse. Los registros expiran según la ventana de retención de eventos del proyecto.

Desconecta al agente del proyecto seleccionado tras una prueba reciente. El proyecto debe ser una de las membresías de la persona. Las conexiones pendientes y las emisiones de credenciales se cancelan; no se emite ningún token de reemplazo. Un miembro limitado a pantallas no conecta agentes, no emite credenciales ni administra a las personas del proyecto: outside_screen_scope (pida al propietario del proyecto).

Las notas que este agente escribió en el proyecto de sesión, las más recientes primero, abiertas y resueltas. state es todo (el predeterminado), abierto o resuelto. Pase next_cursor como after; está vacío en la última página. Los cuerpos de las notas son texto plano escrito por un agente; represéntelos como texto, nunca como HTML o Markdown.

Resuelve una de las notas abiertas del agente como la persona conectada, con una razón obligatoria; resolution.by nombra a la persona. Añade note.resolved con la persona como actor. Una nota resuelta es note_not_open.

Elimina una de las notas del agente, abierta o resuelta, como la persona conectada. Añade note.deleted con la persona como actor.

Las solicitudes de conexión pendientes dirigidas al proyecto de la sesión, que un miembro puede revisar y aprobar: solicitudes que nombran el proyecto, e inicios de sesión o conexiones de dispositivo por una identidad de agente ya miembro de él.

El inicio de sesión de una nueva instalación no está listado (su pista de proyecto la suministra el cliente); una persona lo alcanza con su código de usuario (POST /api/agent-connections/lookup).

Resuelve el código de usuario de un inicio de sesión de dispositivo pendiente (`screenrig login`), tal como se escribió o completó en la página de conexión, a su conexión, cuya vista de aprobación lo muestra. No aprueba nada. Se ignoran separadores, espacios y mayúsculas. Un código desconocido, usado o inválido es agent_connection_invalid; uno expirado es agent_connection_expired.

Limitado a 5 búsquedas por sesión del panel cada 10 minutos, 20 por dirección cliente por hora y 1200 por hora en toda la flota (rate_limited). Un miembro limitado a pantallas no conecta agentes, no emite credenciales ni administra a las personas del proyecto: outside_screen_scope (pida al propietario del proyecto).

Devuelve metadatos de revisión de conexión segura. La revisión no selecciona un proyecto; la aprobación selecciona una de las membresías de la persona.

Aprueba la conexión para el proyecto seleccionado tras una prueba reciente y crea un agente pendiente. El proyecto debe ser una de las membresías de la persona. Devuelve metadatos seguros, nunca el portador. Un miembro limitado a pantallas no conecta agentes, no emite credenciales ni administra a las personas del proyecto: outside_screen_scope (pida al propietario del proyecto).

Deniega la conexión para el proyecto seleccionado tras una prueba reciente sin crear un agente. El proyecto debe ser una de las membresías de la persona. Un miembro limitado a pantallas no conecta agentes, no emite credenciales ni administra a las personas del proyecto: outside_screen_scope (pida al propietario del proyecto).

Una solicitud para el shell del panel.

Cada miembro es el cuerpo que la ruta nombrada responde para esta misma sesión (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 y /api/reviews?state=all&limit=1), producido por el propio controlador de esa ruta bajo sus propias comprobaciones de autorización, de plan y de alcance.

Un miembro está ausente cuando su ruta no respondería 2xx para esta sesión (un rechazo, un rol o un plan que no puede leerla, ningún proyecto actual, un fallo), y entonces el panel lee esa ruta por su cuenta. advertising_network es nulo cuando su ruta respondería 404 not_found porque el proyecto no tiene red.

Una sesión sin proyecto actual recibe los miembros que no necesitan ninguno.

Contadores de estado de red del proyecto para el proyecto de la sesión. Los conteos de pantallas en línea se derivan de flujos de eventos en tiempo real emparejados, la misma derivación que publica Screen.online; no son un booleano almacenado ni un latido del reproductor. Los bytes de medios son solo los bytes duraderos de medios listos.

Estado veraz de capacidad de pago. rails_available es falso y unavailable_reason es financial_rails_unavailable mientras las vías de tarjeta, impuestos y retiro están no disponibles. No se devuelven credenciales bancarias sin procesar.

Un recibo/documento fiscal finalizado propiedad del solicitante. No existe recibo mientras la recaudación de dinero no se ha enviado, por lo que esto es not_found en lugar de un documento fabricado.

Devuelve el saldo público de créditos completos del proyecto de la sesión. Esta lectura autenticada por cookie nunca descuenta, por lo que permanece disponible en cero. El dashboard solo con cookie nunca presenta un portador de proyecto a GET /api/project.

Genera un único ticket de lanzamiento de treinta segundos para un solo uso de la última versión lista de una aplicación que posee el proyecto de la sesión, en el host de vista previa exacto de esa versión, nunca en el marco del host de lanzamiento de Players, para que un Player y el dashboard en un mismo navegador nunca compartan documentos en caché ni otorguen cookies de ese host.

El ticket se convierte en la cookie release-grant solo en ese host, por lo que la vista previa es cross-origin por construcción y el código de la aplicación web nunca puede leer una cookie del dashboard. La respuesta release_id identifica la versión exacta elegida para este lanzamiento, aunque otra publicación termine más tarde. Asigne launch_url a iframe.src y a nada más.

La autoridad aquí es la autoridad del propietario: el proyecto de la sesión posee la aplicación. Esa es una fuente deliberada de segunda autoridad junto con la autoridad exacta del manifiesto actual para screenrig.webapp-package/v1, y está limitada a esta operación. No la generalice a multimedia ni a contenido protegido en runtime.

No hay player padre, por lo que el SDK del navegador y el puente clave-valor fallan cerrado y la vista previa es solo presentación. Una aplicación sin versión lista es resource_conflict.

Una organización tal como la muestra al llamador un elemento de GET /api/organizations, con admin, home y reseller. Una persona con sesión iniciada la lee cuando la administra, administra el revendedor en el que está delegada, es personal o la vería en ese listado (miembro de uno de sus proyectos activos, o es su organización principal).

Cualquier otra persona, y una organización que no existe, reciben 404 not_found. No otorga membresía de proyecto. Solo sesiones por cookie; se rechaza una credencial de agente.

Los administradores de la organización solo leen nombres de proyectos, propietarios, estado y conteos de pantallas; esto no concede acceso a proyectos. Un administrador lee el contenido de un proyecto solo después de unirse a él (POST .../projects/{project_id}/access), y gestiona a sus personas con las rutas de propietario y de miembros de abajo.

Los revendedores activos cuya organización administra la persona con sesión iniciada (admin_user_ids), ordenados por nombre; vacío para todos los demás. Solo sesiones por cookie. Un revendedor es una organización que el personal convirtió en revendedor o que uno de sus administradores registró (POST /api/resellers); sus administradores gestionan las organizaciones de sus clientes (docs/resellers.md).

Un administrador de una organización la convierte en revendedor al instante. El llamador debe ser una persona con sesión iniciada y dirección de correo electrónico verificada (solo sesiones por cookie; los agentes y los clientes de servicio nunca tienen autoridad de revendedor) y administrador de la organización indicada por organization_id; cualquier otra persona recibe 404 not_found.

El revendedor comienza con 2000 puntos básicos del precio de lista (20%), vigentes desde ahora, y queda pendiente de revisión; puede incorporar hasta 10 clientes actuales (customer_limit) hasta que screenRIG lo revise. La organización debe estar activa, no ser ya un revendedor, no ser cliente de un revendedor y no estar en el plan de personal ni promocional (409 reseller_conflict, el detalle indica el motivo).

Añade reseller.enrolled a la auditoría de la organización.

Un revendedor que el llamador administra, con su margen. Cualquier otra persona recibe 404 not_found.

Los clientes actuales del revendedor (organizaciones delegadas en él), ordenados por nombre, con plan, recuentos y bytes almacenados. Solo administradores del revendedor; cualquier otra persona recibe 404 not_found.

Crea una organización cliente delegada en el revendedor desde su creación, en Standard, con el administrador del revendedor que llama como su único administrador. La organización principal del llamador no cambia. Los administradores propios de la organización pueden terminar después la delegación (DELETE /api/organizations/{org_id}/reseller).

Añade organization.created y reseller.customer_started a la auditoría de la organización. Un revendedor pendiente de revisión (review_state pending) incorpora hasta customer_limit clientes actuales; más allá, la respuesta es 409 reseller_conflict.

Un cliente actual del revendedor. Solo administradores del revendedor; una organización que no es cliente actual responde 404 not_found.

Establece el plan de un cliente actual, que paga el revendedor. standard quita el plan; plus y premium se permiten siempre, education solo para una organización apta para Education. Enterprise, staff y promo los asigna el personal.

Un plan superior se aplica de inmediato; uno inferior, o la eliminación del plan, en el siguiente límite mensual UTC, como los cambios de plan de la organización (docs/billing-rollup.md). Añade reseller.customer_plan a la auditoría de la organización.

Los proyectos activos de un cliente actual, con nombres, estado, número de pantallas y si el llamador ya es miembro. Listar no otorga acceso a ningún proyecto; POST .../access permite unirse a uno.

Convierte al administrador del revendedor que llama en miembro completo del proyecto de un cliente actual (can_approve, sin ámbitos, source reseller_admin), igual que lo hace la unión de un administrador de la organización, para que pueda abrirlo con PUT /api/session/project. Si ya es miembro, responde con el proyecto sin cambios.

Añade member.added_by_reseller al proyecto y reseller.project_joined a la auditoría de la organización, y envía un correo electrónico al propietario del proyecto. La membresía permanece hasta que se quita; terminar la delegación no la quita.

Lo que el revendedor debe por un mes UTC. Una línea por cada cliente delegado en cualquier momento del mes, con la parte de sus cargos de uso, en la parte delegada del mes, que su propio crédito no cubrió (al precio de lista y al precio del revendedor), y el precio anual de su plan.

El precio del revendedor es el de lista menos el margen vigente en la fecha posterior entre el inicio del mes y la (re)creación del revendedor. Solo administradores del revendedor.

Un administrador de la organización pone fin de inmediato a su delegación en su revendedor. A partir de entonces la organización paga por sí misma; su plan, proyectos y miembros permanecen como están, incluidas las membresías que tienen los administradores del revendedor. El uso excedente que acumuló su billetera durante la delegación, y que se factura al revendedor, se anula en el mismo cambio.

Añade reseller.customer_ended a la auditoría de la organización. Una organización sin revendedor responde 404 not_found.

Proyectos en otros lugares cuyos propietarios tienen un correo electrónico verificado en el dominio verificado exacto. Las direcciones de contacto y subdominios no coinciden, y los administradores no pueden importar proyectos.

Abra un desafío DNS TXT de 7 días para un dominio, reemplazando el desafío pendiente de ese dominio; los otros dominios de la organización permanecen sin cambios. Coloque su valor exacto en el nombre DNS devuelto y manténgalo allí. Una organización tiene como máximo 20 dominios, verificados y pendientes juntos (resource_conflict). Un dominio que otra organización posee es resource_conflict.

Un dominio que esta organización ya posee puede probarse de nuevo, lo que registra el nuevo valor para la comprobación diaria de DNS.

Verifique un desafío no expirado contra DNS y agregue su dominio a la organización, además de los dominios que ya posee. Cada dominio exacto pertenece a una organización. Se rechaza una prueba rotada durante la búsqueda. Mantenga el registro TXT en su lugar; una verificación diaria elimina un dominio cuyo registro falta durante siete días.

Una vez que la reclamación se confirma, y en segundo plano tras esta respuesta, cada proyecto cuyo propietario sea una persona verificada en exactamente el dominio y que esté solo en la organización personal de ese propietario se mueve a esta organización (renombrada "<name> (<owner>)" en caso de conflicto de nombre).

Los proyectos en cualquier otra organización, proyectos con un plan pagado por el cliente propio, y proyectos que su propietario o personal movieron fuera de una organización de dominio permanecen donde están; un proyecto que los límites de la organización rechazan se reintenta un día después. La ubicación no concede acceso.

Un administrador designado lee los administradores de la organización, los candidatos que pueden serlo (propietarios verificados y activos de sus proyectos en vivo que aún no son administradores) y la revisión de la organización. Cualquier otro es rechazado como en otras rutas de administrador de organización. Solo personas; agentes y credenciales portadoras no tienen ruta de administrador.

Un administrador designado reemplaza a los administradores de la organización. If-Match lleva la revisión de la organización; una desactualizada es revision_conflict con current_revision. El conjunto nombra de 1 a 20 personas, cada una un administrador actual o un candidato, de lo contrario invalid_request; un administrador se elimina solo mientras queda otro administrador.

El cambio incrementa la revisión, se registra en la auditoría de la organización, no otorga membresía de proyecto y devuelve la misma forma que GET. Solo personas; agentes y credenciales portadoras no tienen ruta de administrador.

Un administrador designado lee las personas de la organización. Solo lectura. projects lista los proyectos activos de la organización, ordenados por nombre, máximo 500. people es la unión de los miembros de la organización (member true), las membresías activas de esos proyectos (se excluyen las suspendidas) y los administradores designados.

Se ordena con los administradores primero, luego los miembros de la organización y después las personas externas (las que no son miembros de la organización), cada grupo por nombre visible y luego email.

Cada persona lleva su rol en cada proyecto (owner o member), si puede aprobar revisiones allí (can_approve) y si está limitada a pantallas o cargas (limited), si es administrador, si es miembro de la organización (member), si está administrada por la organización (managed) y, para una persona externa, si la política de invitados actual no la admitiría (outside_guest_policy).

Un administrador o miembro de la organización que no está en ningún proyecto aparece con una lista de proyectos vacía. email está vacío si la dirección de la persona no está verificada. Las personas y agentes desactivados nunca aparecen. Se devuelven como máximo 500 personas, siempre incluyendo a los administradores; truncated es verdadero cuando se omitieron personas, proyectos o membresías.

Cualquier otro es rechazado como en las otras rutas de administrador de la organización. Solo personas; los agentes y las credenciales portadoras no tienen ruta.

Un administrador designado lista las invitaciones de administrador de la organización por id, 50 a la vez, después de expirar las que han pasado su tiempo. Las direcciones de los destinatarios son visibles para los administradores de la organización, quienes las suministraron. Los tokens y URLs de credenciales nunca se listan. Solo personas; agentes y credenciales portadoras no tienen ruta de administrador.

Un administrador designado invita a personas por correo electrónico para que sean administradores. Aceptar añade a la persona a los administradores de la organización y crea su inicio de sesión si no tiene; no concede membresía de proyecto. Como máximo 20 administradores contando invitaciones pendientes (organization_admin_limit); una dirección cuya persona ya administra la organización es invalid_request.

Las invitaciones por correo electrónico expiran después de siete días; una invitación pendiente a la misma dirección se reutiliza. Los nombres de la organización y del remitente deben ser aptos para correo electrónico. Solo personas; los agentes y credenciales de portador no tienen ruta de administrador.

Un administrador designado revoca una invitación de administrador pendiente y libera su lugar de administrador. Una invitación ya revocada devuelve 204; una aceptada devuelve invitation_consumed; un id que la organización no tiene es not_found. Solo personas; agentes y credenciales portadoras no tienen ruta de administrador.

Un administrador designado lista las invitaciones de miembro de la organización por id, 50 a la vez, después de expirar las que han pasado su tiempo. Las direcciones de los destinatarios son visibles para los administradores de la organización, quienes las suministraron. Los tokens y URLs de credenciales nunca se listan. Solo personas; agentes y credenciales portadoras no tienen ruta de administrador.

Un administrador designado invita a personas por correo electrónico para que se unan a la organización como miembros. Aceptar establece esta organización como la organización principal de la persona, sustituyendo cualquier otra anterior, y crea su inicio de sesión si no tiene; no concede membresía de proyecto.

Una dirección cuya persona ya es miembro de la organización es invalid_request; una cuya persona es administrada por otra organización es managed_elsewhere. Las invitaciones por correo electrónico expiran después de siete días; una invitación pendiente a la misma dirección se reutiliza. Los nombres de la organización y del remitente deben ser aptos para correo electrónico.

Aceptar una invitación a la organización del personal (plan_id staff) también convierte a la persona en miembro del personal, por lo que solo el personal puede enviarlas, a una dirección por solicitud con una prueba staff_grant vinculada a ella (reauthentication_required si falta). Solo personas; los agentes y las credenciales bearer no tienen ruta de administración.

Un administrador designado revoca una invitación de miembro pendiente. Una invitación ya revocada devuelve 204; una aceptada devuelve invitation_consumed; un id que la organización no tiene es not_found. Solo personas; agentes y credenciales portadoras no tienen ruta de administrador.

Un administrador designado elimina a un miembro de la organización.

En una transacción se borra la organización principal de la persona y terminan sus membresías en todos los proyectos activos de la organización, cada una como lo haría eliminarla de ese proyecto (se revocan las invitaciones por correo electrónico pendientes a él y sus sesiones dejan de resolverlo); las membresías en proyectos de otras organizaciones no se tocan, y ninguna otra organización cambia.

El cambio queda registrado en la auditoría de la organización.

Una persona a la que administra un proveedor de identidad (inicio de sesión único o SCIM) es managed_member; un administrador designado es organization_admin_member (quite primero su puesto de administrador con PUT /api/organizations/{org_id}/admins); una persona que es propietaria de cualquier proyecto activo de la organización es member_owns_projects y el detalle lista los nombres de los proyectos (transfiera primero esos proyectos, no se elimina nada); una persona que no es miembro de la organización, incluida una ya eliminada, es not_found.

Solo personas; los agentes y las credenciales portadoras no tienen ruta de administrador.

Un administrador designado define a quién admite la organización en sus proyectos como invitado, es decir, a personas cuya organización principal es otra o que no tienen ninguna. mode allow (el valor predeterminado) admite a todo invitado, domains admite a un invitado cuya dirección de correo electrónico verificada está en uno de domains, y none no admite a ningún invitado. domains lista de 1 a 20 nombres DNS distintos en minúsculas, obligatorio para mode domains y omitido en los demás casos; cualquier otra cosa es invalid_request.

La política reemplaza a la anterior, incrementa la revisión de la organización, se registra en la auditoría de la organización y responde con la política vigente. Se comprueba cuando la organización concede a un invitado una membresía de proyecto, mediante invitación de miembro del proyecto (al crearla y al aceptarla) y mediante vinculación de grupo SCIM, y rechaza con guest_not_allowed.

El personal y los propios administradores de la organización están exentos, los agentes no se comprueban y los miembros de la organización nunca son invitados. Restringir la política no elimina a nadie; outside_policy cuenta las personas externas que ya están en los proyectos activos de la organización a las que la nueva política no admitiría, y GET /api/organizations/{org_id}/people marca a cada una de ellas (outside_guest_policy).

Solo personas; los agentes y las credenciales portadoras no tienen ruta de administrador.

Un administrador designado establece o quita el proyecto Biblioteca de la organización. project_id nombra uno de los proyectos activos de la organización, o null para quitarlo.

Todos los demás proyectos de la organización leen entonces los medios, las carpetas de medios y las listas de reproducción de la Biblioteca (library=true en GET /api/media, /api/media-folders y /api/playlists, y por id) y los usan en solo lectura: referencias de medios de las páginas, selectores by:folder que nombran una carpeta de la Biblioteca (los selectores de etiqueta y de todos nunca llegan a la Biblioteca), horarios y pilas de las pantallas, y from_template. Solo los miembros de la propia Biblioteca los modifican.

El proyecto Biblioteca no tiene pantallas: un proyecto con pantallas da library_no_screens, y la Biblioteca no admite ninguna después. Establecer una Biblioteca requiere la función de plan library (Premium, Education, Enterprise; de lo contrario, feature_not_in_plan); quitarla nunca la requiere, y una Biblioteca que se conserva tras una rebaja de plan sigue sirviéndose.

Si se quita o sustituye la Biblioteca, las listas de reproducción de los proyectos miembros que nombran sus elementos dejan de poder resolverlos en su siguiente escritura, y las pantallas dejan de recibir sus medios. Un proyecto que es la Biblioteca y se elimina o se mueve fuera de la organización la quita.

Responde con la vista de la organización, se registra en la auditoría de la organización (organization.library_changed) e incrementa la revisión. Solo personas.

Un administrador designado establece el acceso de muchas personas a muchos de los proyectos activos de la organización en una sola solicitud, sin unirse a ninguno.

De 1 a 500 cambios, cada uno nombra un proyecto, una persona y un acceso, sin repetir ningún par (project_id, user_id). member hace a la persona miembro del proyecto sin poder aprobar revisiones (se agrega si no lo es; un aprobador pierde la aprobación), approver un miembro que puede aprobar (se agrega si no lo es), y none deja a la persona sin ser miembro (se quita si lo es).

Todo se aplica en orden en una sola transacción, y un rechazo deshace todo el lote; cada rechazo señala changes[i] (el proyecto o la persona) o changes[i].access en errors[].field.

Un proyecto que no es un proyecto activo de esta organización es not_found; una persona que no es una persona activa (un agente, una persona desactivada, un id desconocido) o que pertenece al personal, una membresía suspendida, y una persona agregada que no es una de las personas de la organización (sus administradores, sus miembros de la organización y los miembros activos de sus otros proyectos activos; cualquier otra persona se une mediante una invitación) son invalid_request; el propietario nunca se establece como member ni none (owner_cannot_leave); un usuario de carga nunca aprueba (resource_conflict, como responde PUT /api/members/{user_id}/approver); quitar al propio administrador es forbidden (un administrador sale mediante DELETE /api/members/{user_id}); y una persona agregada se admite como la admite una invitación, de modo que los miembros de la organización y los administradores de la organización siempre, y una persona externa solo donde la política de invitados la admite ahora (guest_not_allowed).

Se aplican a lo que se agrega el límite de 200 miembros del proyecto y el tope de miembros de su plan (member_limit_reached). La respuesta repite cada cambio en el orden de la solicitud; changed es false para uno cuyo acceso ya estaba vigente, que no escribe ni registra nada.

Cada cambio queda registrado en la auditoría de la organización (organization.project_member_added, organization.project_member_approver_changed u organization.project_member_removed) y en los eventos del proyecto (member.added_by_organization_admin, project.member_approver_changed o member.removed, marcados como del administrador de la organización), y se envía un correo electrónico una sola vez por lote al propietario de cada proyecto, salvo que sea quien hizo el cambio.

Solo personas; los agentes y las credenciales portadoras no tienen ruta de administrador.

Un administrador designado se une a uno de los proyectos activos de la organización como miembro sin alcance de pantallas ni de carga que puede aprobar revisiones. Unirse es lo que da al administrador el contenido del proyecto, que las rutas de la organización nunca muestran.

Un administrador que ya es miembro sin alcance y que puede aprobar recibe 200 con joined false y no cambia nada; un miembro con alcance de pantallas o de carga, o uno que no puede aprobar, pasa a ser un miembro sin alcance que puede aprobar, registrado como una unión.

Se aplica el límite de 200 miembros del proyecto (member_limit_reached); la política de invitados de la organización nunca se aplica a sus propios administradores. La unión se registra en la auditoría de la organización como organization.project_joined y en los eventos del proyecto como member.added_by_organization_admin, y se envía un correo electrónico al propietario del proyecto.

Un proyecto que la organización no tiene, o que fue eliminado, es not_found. Solo personas; agentes y credenciales portadoras no tienen ruta de administrador.

Un administrador designado nombra propietario de uno de los proyectos activos de la organización a una persona, sin unirse al proyecto, desde quien lo es ahora, incluido un propietario cuya cuenta está desactivada.

El nuevo propietario es una persona verificada y activa que es miembro del proyecto o miembro de la organización (un miembro de la organización que no es miembro del proyecto se añade primero como miembro sin alcance de pantallas ni de carga que puede aprobar revisiones; la política de invitados no se aplica a un miembro de la organización); cualquier otra persona es invalid_request en user_id.

Un administrador se nombra propietario solo después de unirse al proyecto (POST /api/organizations/{org_id}/projects/{project_id}/access), y quien no es miembro sin alcance de pantallas ni de carga que puede aprobar es invalid_request en user_id.

El efecto es el de la propia transferencia del propietario, de modo que el alcance de pantallas y el alcance de carga del nuevo propietario se borran y las responsabilidades heredadas del proyecto se le asignan. Nombrar al propietario actual no cambia nada. El cambio queda registrado en la auditoría de la organización como organization.project_owner_changed, y se envía un correo electrónico al propietario anterior y al nuevo.

Se aplica el límite de 200 miembros del proyecto a un miembro de la organización añadido (member_limit_reached). Un proyecto que la organización no tiene, o que fue eliminado, es not_found. Solo personas; agentes y credenciales portadoras no tienen ruta de administrador.

Un administrador designado elimina a un miembro de uno de los proyectos activos de la organización sin unirse al proyecto. Tiene el efecto de la eliminación por parte del propietario (DELETE /api/members/{user_id}). La membresía termina, se revocan las invitaciones por correo electrónico pendientes de la persona al proyecto, sus sesiones dejan de resolver el proyecto y las membresías de agentes permanecen.

El propietario nunca se elimina (owner_cannot_leave; primero transfiera la propiedad con PUT /api/organizations/{org_id}/projects/{project_id}/owner). Una persona que no es miembro del proyecto, incluida una ya eliminada, y un proyecto que la organización no tiene o que fue eliminado, son not_found.

La eliminación se registra en la auditoría de la organización como organization.project_member_removed y en los eventos del proyecto como member.removed con removed_by_organization_admin true. Solo personas; los agentes y las credenciales portadoras no tienen ruta de administrador.

Eliminar un dominio, verificado o pendiente, y dejar los otros dominios de la organización. La colocación y descubrimiento futuros para él se detienen, y otra organización puede verificarlo. Los proyectos ya en la organización permanecen. Un dominio que la organización no posee ni está verificando es not_found.

Mientras la organización exija el inicio de sesión único, un dominio verificado es resource_conflict; desactivar Exigir inicio de sesión único surte efecto después de 72 horas, y entonces se puede quitar el dominio.

Define si un miembro puede aprobar: decidir revisiones y otorgar a agentes el acceso Gestionar. Un miembro que no puede aprobar tiene a sus agentes limitados a Proponer. Solo el propietario del proyecto o un miembro que administra la organización del proyecto (forbidden de lo contrario); la fila del propio propietario es fija (resource_conflict); un no miembro es not_found.

Añade project.member_approver_changed (detalles user_id, can_approve).

Limita a un miembro a carpetas de pantallas (cada una con todas las carpetas que contiene) y pantallas, o reemplaza el alcance de uno (docs/screen-scope.md).

En una sola transacción también termina los agentes que la persona trajo al proyecto (agent.disconnected, como lo haría quitarlos) y añade project.member_screen_scope_changed (detalles user_id, screen_scope, previous, changed_by_user_id). El alcance se lee en la siguiente solicitud del miembro: el cambio se ve en su próximo GET /api/session sin volver a iniciar sesión.

Solo el propietario del proyecto o un miembro que administra la organización del proyecto (forbidden de lo contrario); la fila del propio propietario, un usuario de carga (un miembro con alcance está limitado a pantallas, un usuario de carga a contenido) y un miembro que aprueba revisiones con pantallas individuales en el alcance son resource_conflict; un no miembro es not_found; un id que no es una carpeta de pantallas ni una pantalla vivas del proyecto es invalid_request en screen_scope.folder_ids[i] o screen_scope.screen_ids[i].

Un miembro con alcance que aprueba revisiones aprueba solo dentro del alcance; quien no puede aprobar lee y ejecuta comandos, pero cambia lo que se reproduce solo a través de aprobadores (approver_required).

Un alcance también se rechaza con resource_conflict mientras la persona, o un agente que trajo, tenga un cliente de servicio activo del proyecto: el detalle nombra hasta cinco clientes como ID (name) y cuenta el resto, y no se escribe nada.

Limitar a una persona a pantallas corresponde al alcance de pantallas, que incluye el plan Enterprise; un proyecto cuyo plan no lo incluye se rechaza con feature_not_in_plan (402). Un alcance establecido sigue limitando a la persona hasta que se borra (DELETE), lo que puede hacer cualquier plan.

Devuelve a un miembro con alcance todas las pantallas del proyecto. Solo el propietario del proyecto o un miembro que administra la organización del proyecto; un miembro sin alcance se deja como está. Añade project.member_screen_scope_changed con screen_scope null.

Limita la membresía de un agente en el proyecto de la sesión a carpetas de pantallas y pantallas, o reemplaza su alcance (docs/screen-scope.md). El alcance del agente es este alcance restringido por el de la persona responsable de él, así que una persona con alcance nunca actúa a través de un agente más amplio que ella.

Solo el propietario del proyecto o un miembro que administra la organización del proyecto (forbidden de lo contrario); un agente que no es miembro del proyecto es not_found. Añade agent.screen_scope_changed (detalles agent_id, screen_scope, previous, changed_by_user_id).

El alcance de un agente se aplica en su siguiente solicitud en la instancia que lo escribió y en dos segundos en las demás. Un alcance se rechaza con resource_conflict mientras el agente tenga un cliente de servicio activo del proyecto: el detalle nombra hasta cinco clientes como ID (name) y cuenta el resto, y no se escribe nada.

Limitar a un agente a pantallas corresponde al alcance de pantallas, que incluye el plan Enterprise; un proyecto cuyo plan no lo incluye se rechaza con feature_not_in_plan (402). Un alcance establecido sigue limitando al agente hasta que se borra (DELETE), lo que puede hacer cualquier plan.

Quita el alcance de la membresía de un agente en el proyecto de la sesión. Solo el propietario del proyecto o un miembro que administra la organización del proyecto. Añade agent.screen_scope_changed con screen_scope null.

Convierte a un miembro en usuario de carga, o reemplaza el alcance de uno (docs/uploaders.md): las listas de reproducción cuyas páginas cambia y las carpetas de medios en las que sube.

En una sola transacción también les impide aprobar revisiones, finaliza los agentes que trajeron al proyecto (agent.disconnected, como lo haría eliminarlos) y añade project.member_upload_scope_changed (detalles user_id, upload_scope, changed_by_user_id).

El alcance se lee en la siguiente solicitud del miembro: el cambio se ve en su próximo GET /api/session sin volver a iniciar sesión.

Solo el propietario del proyecto o un miembro que administra la organización del proyecto (forbidden de lo contrario); la propia fila del propietario es resource_conflict; un no miembro es not_found; un id que no es una lista de reproducción o carpeta de medios activa del proyecto es invalid_request en upload_scope.playlist_ids[i] o upload_scope.folder_ids[i]. access propose (el valor predeterminado) envía los cambios del usuario de carga a revisión; manage los publica.

Un miembro limitado a pantallas es resource_conflict: quite primero ese alcance (DELETE /api/members/{user_id}/screen-scope).

Vuelve a convertir a un usuario de carga en miembro completo, que no aprueba revisiones (actívelo con setDashboardMemberApprover). Solo el propietario del proyecto o un miembro que administra la organización del proyecto; un miembro que no es usuario de carga se deja como está. Añade project.member_upload_scope_changed con upload_scope en null.