API-Referenz

Schema-Index

Generierte Namen, Pflichtfelder und Schema-Beschreibungen; für vollständiges JSON-Schema rohes OpenAPI verwenden.

Schemaindex

  • AccessLevel — erforderlich: none

    lesen (Nur lesen) < vorschlagen < verwalten. Vorschlagen liest, trägt bei (Medien, Notizen, Kommentare, Support, Feedback, Screenshots, Anzeigenentwürfe) und wandelt Playlist- und Bildschirmänderungen in Prüfungen um (docs/reviews.md).

  • AccessLimitedBy — erforderlich: none

    Warum effective_access niedriger ist als der Zugriff der Anmeldeinformationen. Projekt – das Projekt erfordert eine Überprüfung von Agentenänderungen. Person – die verantwortliche Person des Agenten ist ein Mitglied, das keine Überprüfungen genehmigen kann.

  • AdslotPageWrite — erforderlich: id, type, adslot_id

    Ganzseitiger Werbeplatz. Maximal 16 Adslot-Seiten und mindestens eine normale Seite ohne Sichtbarkeit sind Serverprüfungen und werden hier nicht ausgedrückt.

  • AdvertisingAvailability — erforderlich: estimated_plays, booked_plays, available_plays, screens, observed_from, observed_to, flight_start, flight_end

    Eine Schätzung: die Slot-Vorkommen, die die Zielbildschirme im beobachteten Fenster erzeugt haben, hochgerechnet auf die Laufzeit, abzüglich der Wiedergaben, die andere Direktziele auf denselben Bildschirmen noch benötigen.

  • AdvertisingAvailabilityQuery — erforderlich: flight_start, flight_end
  • AdvertisingCampaign — erforderlich: id, revision, name, state, pause_reasons, price_change_pending, daily_cap_mcr, lifetime_cap_mcr, reserved_mcr, spent_mcr, flight_start, flight_end, networks, created_at, updated_at
  • AdvertisingCampaignDraft — erforderlich: name, daily_cap_mcr, lifetime_cap_mcr, flight_start, flight_end, networks
  • AdvertisingCampaignList — erforderlich: campaigns
  • AdvertisingCampaignNetwork — erforderlich: seller_project_id, membership_id, admission_generation, screen_ids, slot_ids, creative_ids, network_cap_mcr, network_reserved_mcr, network_spent_mcr, accepted_pricing_generation, price_change_pending, barrier_generation, enabled
  • AdvertisingCampaignNetworkDraft — erforderlich: seller_project_id, screen_ids, slot_ids, creative_ids
  • AdvertisingCategory — erforderlich: none

    Die Kategorie des Werbetreibenden. Zwei Anzeigen einer Kategorie laufen auf einem Bildschirm nie im selben Werbeblock; eine Anzeige ohne Kategorie wird nie getrennt.

  • AdvertisingCreative — erforderlich: id, revision, media_id, media_revision, sha256, kind, content_type, duration_ms, width, height, bytes, state, created_at
  • AdvertisingCreativeCreate — erforderlich: media_id
  • AdvertisingCreativeList — erforderlich: creatives
  • AdvertisingCreativeReview — erforderlich: id, seller_project_id, creative_revision, state, created_at
  • AdvertisingDaypart — erforderlich: start, end
  • AdvertisingDeliveryReport — erforderlich: gross_mcr, fee_mcr, net_mcr, completed, interrupted, unbillable, rows, coverage
  • AdvertisingDeliveryRow — erforderlich: screen_id, slot_id, reservation_id, gross_mcr, fee_mcr, net_mcr, completed_at
  • AdvertisingDirectCampaign — erforderlich: id, revision, name, advertiser, state, flight_start, flight_end, reserved_plays, delivered_plays, media_ids, image_duration_ms, screen_ids, slot_ids, venue_types, cities, tags, dayparts, overbooked, pace, created_at, updated_at
  • AdvertisingDirectCampaignDraft — erforderlich: name, advertiser, flight_start, flight_end, media_ids

    Eine Direktkampagne: das eigene Geschäft des Verkäufers mit einem externen Werbetreibenden über das eigene Werbeinventar des Verkäufers. Sie bewegt kein Geld.

  • AdvertisingDirectCampaignList — erforderlich: direct_campaigns
  • AdvertisingDirectPace — erforderlich: status, expected_plays

    Auslieferung gegenüber dem Ziel, das sich gleichmäßig über die Laufzeit aufbaut.

  • AdvertisingDirectPrice — erforderlich: model, amount, currency

    Der vom Verkäufer erfasste Preis des Geschäfts. screenRIG berechnet ihn nie; er bewertet den Bericht.

  • AdvertisingDirectReport — erforderlich: campaign_id, name, advertiser, from, to, delivered_plays, reserved_plays, pace, plays, played_ms, not_played, rows
  • AdvertisingDirectReportRow — erforderlich: day, screen_id, slot_id, media_id, plays, played_ms
  • AdvertisingDirectValue — erforderlich: model, amount, currency

    Der erfasste Preis, angewandt auf die ausgelieferten Wiedergaben: pro tausend Wiedergaben bei cpm, die gesamte Gebühr bei flat.

  • AdvertisingFillStats — erforderlich: from, to, occurrences, direct, marketplace, vast, unfilled, fill_rate, unfilled_reasons, days

    Das Werbeslot-Angebot des Verkäufers für alle UTC-Stunden, die das angefragte Fenster überlappen: angefragte Vorkommen, Befüllungen nach Quelle und ungefüllte Vorkommen mit dem Grund der ersten Anfrage. Die Anfrage umfasst höchstens 35 Tage; die effektiven Grenzen können 35 Tage plus eine Stunde umfassen.

  • AdvertisingFillStatsDay — erforderlich: day, occurrences, direct, marketplace, vast, unfilled, fill_rate
  • AdvertisingInventory — erforderlich: screen_id, revision, ads_enabled, audience_tags, rate_override_mcr_per_15s, rate_revision, created_at, updated_at
  • AdvertisingInventoryList — erforderlich: inventory
  • AdvertisingInventoryWrite — erforderlich: ads_enabled
  • AdvertisingJoinedInventory — erforderlich: inventory, slots
  • AdvertisingJoinedNetwork — erforderlich: seller_project_id, membership_id, policy, admission_generation, scope, price_change_pending, default_rate_mcr_per_15s
  • AdvertisingJoinedNetworkList — erforderlich: networks
  • AdvertisingMembership — erforderlich: id, seller_project_id, admission_generation, policy_revision, policy, scope, state, revision, created_at, updated_at
  • AdvertisingMembershipList — erforderlich: memberships
  • AdvertisingMembershipScope — erforderlich: policy, screen_ids, slot_ids
  • AdvertisingNetwork — erforderlich: id, revision, enabled, rate_revision, pricing_generation, seller_fee_bps, seller_fee_revision, created_at, updated_at
  • AdvertisingNetworkCreate — erforderlich: name
  • AdvertisingQuote — erforderlich: id, campaign_id, campaign_revision, revision, state, expires_at, items, pricing_generations, created_at
  • AdvertisingQuoteAccept — erforderlich: quote_id
  • AdvertisingQuoteItem — erforderlich: seller_project_id, screen_id, slot_id, creative_id, duration_ms, rate_mcr_per_15s, play_price_mcr, pricing_generation, fee_bps, fee_revision
  • AdvertisingRate — erforderlich: rate_mcr_per_15s
  • AdvertisingReportCoverage — erforderlich: mode, outcomes_complete

    Abdeckung der Wiedergabe-Ergebniszählungen. Monetäre Gesamtsummen stammen immer aus unveränderlichen Abrechnungen. Wenn outcomes_complete falsch ist, sind Zählungen beobachtete Untergrenzen und fehlende Historie nicht verfügbar, nicht null.

  • AdvertisingReview — erforderlich: id, creative_id, creative_revision, state, created_at
  • AdvertisingReviewDetail — erforderlich: review, creative
  • AdvertisingReviewList — erforderlich: reviews
  • AdvertisingReviewRejection — erforderlich: reason
  • AdvertisingScope — erforderlich: screen_ids, slot_ids
  • AdvertisingSellerCampaign — erforderlich: id, buyer_project_id, name, state, flight_start, flight_end, screen_ids, slot_ids, creative_ids, review_state, enabled, price_change_pending, updated_at

    Eine eingereichte Käuferkampagne, allein auf das Netzwerk des aufrufenden Verkäufers projiziert.

  • AdvertisingSellerCampaignDelivery — erforderlich: completed, reserved_mcr, gross_mcr, fee_mcr, net_mcr

    Abgerechnete Plays und Beträge über die gesamte Laufzeit im Netzwerk des aufrufenden Verkäufers sowie der aktuell reservierte Betrag.

  • AdvertisingSellerCampaignDetail — erforderlich: campaign, delivery
  • AdvertisingSellerCampaignList — erforderlich: campaigns
  • AdvertisingSlot — erforderlich: id, revision, name, enabled, accepted_media, max_image_duration_ms, max_video_duration_ms, muted, rate_override_mcr_per_15s, rate_revision, created_at, updated_at
  • AdvertisingSlotList — erforderlich: slots
  • AdvertisingSlotWrite — erforderlich: name, accepted_media, max_image_duration_ms, max_video_duration_ms
  • AdvertisingSpendReport — erforderlich: campaign_id, spent_mcr, reserved_mcr, completed, unbillable, pending, coverage
  • Agent — erforderlich: id, name, agent_type, capabilities, state, authenticated_requests, metered_credits, created_at
  • AgentCapability — erforderlich: none

    Ein Bereich der Agent-Anmeldefähigkeiten. Fähigkeiten sind festgelegt, wenn die Anmeldeinformationen erstellt werden; um sie zu ändern, verbinden Sie einen neuen Agenten und trennen den alten. Die kanonische Reihenfolge ist diese Enum-Reihenfolge; Fähigkeitslisten enthalten niemals Duplikate.

  • AgentConnection — erforderlich: connection_id, name, agent_type, status, capabilities, expires_at, created_at
  • AgentDisconnectRequest — erforderlich: none
  • AgentInput — erforderlich: none
  • AgentList — erforderlich: items
  • AgentScreenScopeUpdate — erforderlich: screen_scope
  • AgentSelfStatus — erforderlich: agent, connection_ready
  • Alert — erforderlich: id, screen_id, condition, state, since, muted, attention

    Eine Bildschirmbedingung, solange sie andauert. Clients, die Alarme lesen, behandeln eine unbekannte Bedingung als eine Bedingung, die sie nicht benennen können.

  • AlertAcknowledge — erforderlich: none
  • AlertActor — erforderlich: kind, id
  • AlertList — erforderlich: items, next_cursor, counts
  • AlertMute — erforderlich: id, screen_ids, tags, until, created_at
  • AlertMuteList — erforderlich: items
  • AlertMuteWrite — erforderlich: until

    Mindestens eine Bildschirm-ID oder ein Tag.

  • AppStoreNotificationAcknowledgement — erforderlich: acknowledged
  • AppStoreNotificationRequest — erforderlich: signedPayload
  • AppStoreOffer — erforderlich: account_token, products, education_eligible, education_eligibility_source, can_purchase, current_plan_id, subscription
  • AppStoreProduct — erforderlich: product_id, plan_id
  • AppStoreSubscription — erforderlich: organization_id, plan_id, product_id, original_transaction_id, environment, expires_at, auto_renews, status

    Das App-Store-Abonnement einer Organisation.

  • AppStoreTransactionRequest — erforderlich: signed_transaction
  • Application — erforderlich: id, name, revision, created_at, updated_at
  • ApplicationEventContext — erforderlich: primitive_id, code
  • ApplicationEventReport — erforderlich: severity, code, context
  • ApplicationList — erforderlich: items
  • ApplicationPlacement — erforderlich: playlist_id, playlist_name, page_id, primitive_id, release_id, release, controller, rect, canvas, screen_count

    Ein Anwendungsprimitiv auf einer Seite einer Playlist.

  • ApplicationRename — erforderlich: name
  • ApplicationUploadCommit — erforderlich: sha256, compressed_bytes

    Nennt das erklärte Archiv erneut; ein Commit, der andere Bytes nennt, wird mit invalid_request abgelehnt.

  • ApplicationUploadDeclaration — erforderlich: sha256, compressed_bytes, expanded_bytes, file_count

    Erklärt ein von der CLI erzeugtes tar.gz, mit den Metadaten, die ein gestreamter Upload als Header sendet.

  • ApplicationUploadSession — erforderlich: id, application_id, release_id, operation, upload_url, method, headers, expires_at
  • ApplicationUsage — erforderlich: placements, screens
  • ArchivedProjectDevice — erforderlich: screen_id, label, host
  • AuditActor — erforderlich: kind
  • AuditActorKind — erforderlich: none
  • AuditClient — erforderlich: kind
  • AuditEntry — erforderlich: id, scope, at, actor, source, action, resource, changes
  • AuditFieldChange — erforderlich: path, before, after
  • AuditHead — erforderlich: scope, seq, hash, floor_seq, floor_hash, unsealed, format
  • AuditList — erforderlich: items, next_cursor
  • AuditProblem — erforderlich: seq, code, detail
  • AuditResource — erforderlich: type
  • AuditRevision — erforderlich: type
  • AuditSource — erforderlich: none

    Die Oberfläche, über die eine Änderung kam: eine Dashboard-Sitzung, die HTTP-API, die screenrig-CLI, ein MCP-Tool-Aufruf, ein Mitarbeiter mit Schreibfreigabe, ein signierter Geräteaufruf, ein eingehender Webhook oder der Server selbst (ein Worker, der eine genehmigte Änderung anwendet).

  • AuditVerifyResult — erforderlich: ok, scope, checked, head, problems
  • AutoTopUpDisabledSettings — erforderlich: enabled

    Das Deaktivieren bewahrt gespeicherte Beträge und die monatlichen Ausgaben. Optionale Betragsfelder werden ignoriert, auch unfertige Entwürfe.

  • AutoTopUpEnabledSettings — erforderlich: enabled, threshold_cents, amount_cents, monthly_limit_cents
  • AutoTopUpSettings — erforderlich: none
  • AutoTopUpView — erforderlich: enabled, threshold_cents, amount_cents, monthly_limit_cents, paused, this_month_cents
  • BIBrowse — erforderlich: items, next_cursor

    Grafana: dashboards (uid, title, folder, tags), or with dashboard set that dashboard's panels (id, title, type) and the dashboard itself. Power BI: workspaces (id, name), or with workspace set that workspace's reports (id, name, embed_url) and the workspace itself. Tableau: views (path as Workbook/View, name).

  • BICheck — erforderlich: name, ok
  • BIConnection — erforderlich: id, project_id, kind, name, config, embed_origin, secret, last_test, revision, created_at, updated_at

    Der Zugriff eines Projekts auf ein BI-System. Jede Verbindung gehört zu genau einem Projekt.

  • BIConnectionConfig — erforderlich: none
  • BIConnectionList — erforderlich: items, next_cursor
  • BIConnectionPatch — erforderlich: none
  • BIConnectionWrite — erforderlich: name, kind, config
  • BISecret — erforderlich: set, hint

    Wie ein gespeichertes Secret angezeigt wird. Das Secret selbst wird nie zurückgegeben.

  • BITarget — erforderlich: none

    Was eine Ansicht zeigt. Grafana mit einer Verbindung: dashboard_uid (und optional ein Panel). Power BI mit einer Verbindung: workspace_id und report_id, mit pages oder rotate_all_pages. Tableau mit einer Verbindung: view (Workbook/View), mit rotate_sheets. Web mit einer Verbindung: url. Ohne Verbindung: nur public_url (und rotate_sheets für Tableau).

  • BITestReport — erforderlich: at, ok, checks
  • BIView — erforderlich: id, project_id, kind, name, target, refresh_s, rotate_s, fit, revision, status, embed_url, created_at, updated_at
  • BIViewError — erforderlich: at, code, detail
  • BIViewList — erforderlich: items, next_cursor
  • BIViewPatch — erforderlich: none
  • BIViewStatus — erforderlich: last_ok_at, last_error

    Wie die Ansicht zuletzt auf dem Bildschirm abgeschnitten hat. Sie ändert sich nur, wenn sich das Ergebnis ändert.

  • BIViewTest — erforderlich: at, ok, checks
  • BIViewWrite — erforderlich: name

    Setzen Sie connection_id mit genau einem von url und target (bei Tableau darf url mit einem target kommen, das nur rotate_sheets enthält; eine Web-Ansicht nimmt url und kein target), oder kind (grafana, powerbi oder tableau) mit target.public_url allein.

  • BIWebCookie — erforderlich: name, value, domain

    Ein Cookie aus einem Cookie-Satz, der aus einem angemeldeten Browser exportiert wurde.

  • BIWebSession — erforderlich: state, cookies, cookies_updated_at, last_login_at, login_failures, retry_at

    Cookies und Anmeldung einer Web-Verbindung. state: idle (noch nichts; die erste Aufnahme meldet sich an), active, login_needed (die Seite zeigte ihre Anmeldeseite; die nächste Aufnahme meldet sich an), paused (eine Anmeldung war nicht erfolgreich; die nächste wartet bis retry_at), stopped (fünf abgelehnte Anmeldungen in Folge; ändern Sie die Zugangsdaten) oder expired (eine Verbindung nur mit Cookies, deren Cookies nicht mehr funktionieren; geben Sie ihr einen neuen Cookie-Satz).

  • BIWebStep — erforderlich: action

    Ein Schritt einer skriptgesteuerten Anmeldung. goto: url (https, öffentlich). fill: selector und value. click und wait_for: selector. press: value, ein Tastenname wie Enter oder Tab, und optional selector, der zuerst den Fokus erhält. wait_ms: ms.

    Ein Wert kann {{username}}, {{password}} und {{otp}} enthalten, die der Renderer aus der Anmeldung füllt; schreiben Sie kein Passwort und keinen Code in einen Wert, nur den Platzhalter.

  • BillingBalance — erforderlich: wallet_revision, remaining_mcr, reserved_mcr, available_mcr, sources, withdrawal
  • BillingPayer — erforderlich: kind, id
  • BillingPaymentMethod — erforderlich: brand, last4, exp_month, exp_year
  • BillingPayoutStatus — erforderlich: rails_available, unavailable_reason
  • BillingPlanSubscription — erforderlich: subscription_id, plan, status, entitlement, cancel_at_period_end
  • BillingPortalSession — erforderlich: url
  • BillingSourceBucket — erforderlich: remaining_mcr, reserved_mcr
  • BillingSources — erforderlich: nonredeemable, purchased, ad_earned
  • BillingStatement — erforderlich: entries, next_cursor
  • BillingStatementEntry — erforderlich: sequence, journal_id, kind, amount_mcr, amount_credits, amount_usd, occurred_at
  • BillingUsageAllowance — erforderlich: storage_bytes, api_events, storage_mcr_per_gb_month

    Was ein Zahler kostenlos erhält, als kanonische Dezimalzeichenfolgen. Bandbreite wird nie berechnet, daher hat sie keine Freimenge.

  • BillingUsageAmounts — erforderlich: bandwidth_bytes, storage_mcr, api_events
  • BillingWithdrawal — erforderlich: eligible_earned_mcr, amount_usd_cents, threshold_exclusive_usd_cents, allowed, blockers, rails_available
  • BrowserLinkClaim — erforderlich: session_id, status, screen
  • BrowserLinkClaimRequest — erforderlich: code
  • BrowserLinkClaimScreen — erforderlich: id, public_id, state, public_url
  • BrowserLinkEvent — erforderlich: session_id, status, event_id, expires_at
  • BrowserLinkSession — erforderlich: session_id, code, display_code, status, expires_at
  • BrowserLinkStatus — erforderlich: session_id, code, display_code, status, continuation_path, expires_at
  • BrowserProvisioningCompletion — erforderlich: screen, public_url
  • BrowserProvisioningExchange — erforderlich: provisioning_token, exchange_id
  • CLIEnrollment — erforderlich: project, agent, connection_ready, token, issuance_id, issuance_expires_at, invitation
  • CLIEnrollmentOAuth — erforderlich: project, agent, connection_ready, issuance_id, issuance_expires_at, invitation, access_token, token_type, expires_in, refresh_token, refresh_expires_at, scope

    Registrierung im OAuth-Zugangsdatenformat. Die Registrierungserlaubnis (Client screenrig-cli, Manage im neuen Projekt mit allen Berechtigungen, Identitätszugriff Manage) stellte ihr erstes Token-Paar aus; ein exaktes Wiederholen vor issuance_expires_at gibt dasselbe Paar zurück, spätere Wiederholungen geben credential_issuance_expired zurück.

  • CLIEnrollmentRequest — erforderlich: client_id
  • Campaign — erforderlich: id, name, playlist_id, audience, priority, paused, reserved, revision, created_at, updated_at

    Eine Inhaltskampagne: Jeder Bildschirm in audience zeigt playlist_id, solange from, until und windows in der Zeitzone des Bildschirms gelten. Fehlen from, until und windows, gilt sie immer.

  • CampaignAudience — erforderlich: none

    Welche Bildschirme eine Kampagne anspricht: genau eines von all (jede Regel trifft zu), any (mindestens eine trifft zu), tag (der Bildschirm trägt das Tag), screen_id (dieser Bildschirm) oder folder (die Bildschirme in diesem Bildschirmordner und in jedem darin enthaltenen Ordner, GET /api/screen-folders; der Ordner muss existieren).

    Regeln verschachteln sich höchstens 3 tief, und eine Zielgruppe hat höchstens 500 Regeln. {"all": []} ist jeder Bildschirm des Projekts; sonst listen all und any mindestens eine Regel auf.

  • CampaignList — erforderlich: items
  • CampaignPatch — erforderlich: none
  • CampaignPreviewRequest — erforderlich: body
  • CampaignPromote — erforderlich: revision
  • CampaignReach — erforderlich: published, current, at, empty_groups

    Auf wie viele aktive Bildschirme die Zielgruppe passt; ein Bildschirm im Pairing wird nicht gezählt.

    Sie zählt Treffer der Zielgruppe, nicht den Ort, an dem die Kampagne läuft: Ein aktiver Bildschirm ohne Standard-Playlist passt und spielt nichts ab. published ist die Anzahl bei der letzten Veröffentlichung der Kampagne (erstellt oder aktualisiert mit anderer Zielgruppe, playlist_id oder paused); current die neueste Anzahl.

    Eine Änderung an Tags, Ordner oder Status eines aktiven Bildschirms oder das Verschieben eines Ordners zählt die Kampagnen, deren Zielgruppe das Geänderte nennt, etwa 15 Sekunden nach Ende der Änderungen neu und hängt campaign.reach_changed (published, previous, current; republished true bei einer Veröffentlichung) an sowie, für jeden Tag oder Ordner der Zielgruppe, der beginnt oder aufhört, auf Bildschirme zu passen, campaign.group_changed (kind, value, matched); eine Veröffentlichung, die einen leeren Tag oder Ordner aus der Zielgruppe entfernt, hängt campaign.group_changed mit removed true und matched 0 an.

    Fehlt bei einer Kampagne, die seit der Einführung der Reichweite weder veröffentlicht noch neu gezählt wurde.

  • CampaignRevision — erforderlich: revision, created_at, change, current, campaign

    Eine gespeicherte Revision einer Kampagne: die Kampagne, wie sie nach einem Schreibvorgang war. change gibt an, was sie erzeugt hat: created, edited (ein Update oder ein Zeitplan-Import), restored oder promoted (eine Kopie einer früheren Revision, benannt durch restored_from) oder baseline (die Revision, die die Kampagne zu Beginn ihres Verlaufs hielt, bevor ein Schreibvorgang eine aufzeichnete).

    Ein Wert, den dieser Leser nicht kennt, gilt als edited.

  • CampaignRevisionList — erforderlich: items
  • CampaignScreens — erforderlich: campaign_id, counts, items
  • CampaignStatus — erforderlich: campaign_id, screen_id, status

    Der Status einer Kampagne auf einem Bildschirm.

    Auf einem Bildschirm, dessen Player seinen eigenen Stapel (schedule.stack) auflöst und empfängt, steht eine zeitlich gültige Kampagne dort, wo dieser Stapel sie einordnet: Eine Streifen- oder Hauptkampagne spielt in ihrer Region und eine Display-Sperre auf ihren Displays; eine im Stapel fehlende Kampagne ist pending oder blocked (playlist_unavailable). playing: Der Bildschirm zeigt sie. pending: Sie sollte erscheinen, der Wechsel erfolgt innerhalb einer Minute. waiting: derzeit außerhalb von from, until oder windows (next_start nennt den Beginn innerhalb der nächsten acht Tage). ended: until ist vorbei. outranked: Sie gilt, aber eine Bildschirmübernahme (reason takeover) oder eine andere Kampagne (reason campaign, by) gewinnt. conditional: Sie gilt zeitlich und spielt, solange auch die nur vom Player beobachtete Bedingung erfüllt ist (reason interaction: Jemand nutzt den Bildschirm; data: ihre Datenbedingung). paused. blocked: Sie kann hier nicht erscheinen (reason no_default_playlist, no_timezone oder playlist_unavailable: Die Wiedergabeliste fehlt, ist nicht freigegeben oder passt nicht zum Bildschirm; region_not_laid_out: Sie ist auf keinem Display dieses Bildschirms angeordnet (ihr Streifen passt auf keines der adressierten Displays oder ihre Display-Sperre nennt keinen Bildschirmausgang) und fehlt im Stapel; oder stack_only: Der Player des Bildschirms löst seinen eigenen Stapel nicht auf, und nur ein Player, der dies tut, berücksichtigt eine Region, Display-Sperre, Interaktion oder Datenbedingung). not_in_audience.

  • CampaignWrite — erforderlich: name, playlist_id, audience
  • CanvasBackground — erforderlich: none

    Solide kanonische Großbuchstaben #RRGGBBAA oder ein linearer Verlauf von oben nach unten.

  • CanvasColor — erforderlich: none

    Kanonisches Großbuchstaben-sRGB RRGGBBAA.

  • CapPull — erforderlich: none

    CAP-Quellen, die die Plattform für den Auslöser liest, mit Zielbildschirmen und welche Alarme zählen: die Parameter einer cap-alert-Kartenplatzierung (docs/feeds.md "CAP alerts"). Jede Quell-URL wird einmal pro Minute für jeden Auslöser und jede Platzierung, die sie nennt, abgerufen.

    Ohne Quellen werden die öffentlichen Feeds der Plattform für den Standort gelesen (NWS, Canada NAAD und MeteoAlarm für einen Standort mit Gebietscodes). Die schwerwiegendste passende Warnung übernimmt die Zielbildschirme genau wie eine Push-Nachricht; wenn die Quellen keine Warnungen zeigen (eine Stornierung oder ein Ablauf), endet eine abgerufene Warnung.

    Eine veraltete oder fehlerhafte Quelle beendet niemals eine Warnung. Standort ist erforderlich, sofern keine Quellen angegeben sind.

  • Capabilities — erforderlich: api_version, protocol_version, application_compressed_bytes, application_expanded_bytes, application_package_bytes, application_file_count, application_file_bytes, application_path_depth, application_path_bytes, media_image_bytes, media_audio_bytes, media_video_bytes, playlist_max_pages, playlist_max_items_per_page, playlist_max_media_per_selector, transition_max_duration_ms, screens_per_project, project_content_bytes, founding_period_ends_at, features
  • CardCatalogue — erforderlich: cards
  • CardCreate — erforderlich: type, params
  • CardDataEntry — erforderlich: key, document, bytes, sha256, revision, created_at, updated_at
  • CardDataList — erforderlich: items, next_cursor
  • CardDataSummary — erforderlich: key, bytes, sha256, revision, created_at, updated_at
  • CardDataWrite — erforderlich: document
  • CardDetails — erforderlich: id, major, version, params_schema, data_schema, feed, tier, layouts, example
  • CardFile — erforderlich: src, sha256
  • CardInstance — erforderlich: id, project_id, type, major, params, created_at, updated_at, revision
  • CardKVWebhook — erforderlich: id, card_id, description, mapping, enabled, signing, url, created_at, updated_at

    Ein eingehender Webhook, der das Datendokument einer Karte schreibt.

  • CardKVWebhookCreate — erforderlich: none
  • CardKVWebhookList — erforderlich: items
  • CardKVWebhookRotate — erforderlich: none
  • CardKVWebhookUpdate — erforderlich: none
  • CardKVWebhookWithSecrets — erforderlich: none
  • CardKVWebhookWriteResult — erforderlich: status
  • CardRequirements — erforderlich: cardml, features
  • CardSummary — erforderlich: id, title, short, category, tags, tier, layouts, majors
  • Comments — erforderlich: comments
  • CommentsWrite — erforderlich: comments
  • Connection — erforderlich: id, project_id, provider, mode, name, status, last_error, config, secret, last_test, revision, created_at, updated_at

    Der wiederverwendbare Zugriff eines Projekts auf Microsoft oder Google. Quellen, Power-BI-Verbindungen und SharePoint-Mediensynchronisierungskonten nennen in config.connection_id eine, statt eigene Zugangsdaten mitzubringen.

  • ConnectionCheck — erforderlich: name, ok, detail
  • ConnectionConfig — erforderlich: none

    Was eine Verbindung außer ihrem Secret benennt; nur die Mitglieder, die ihr Anbieter und ihr Modus verwenden, sind vorhanden. Ein Secret, ein Schlüssel oder ein Aktualisierungs-Token ist nie hier.

  • ConnectionConfigWrite — erforderlich: none

    Microsoft, Modus own_app: beide Mitglieder. Nicht akzeptiert für eine Google-Verbindung oder für den Modus screenrig_app.

  • ConnectionConsent — erforderlich: none

    Eine Verbindung, die mit ihrem einmaligen Zustimmungslink beantwortet wird, den nur ein Schreibzugriff trägt, der einen erzeugt: das Anlegen einer Verbindung im Modus screenrig_app und POST /api/connections/{id}/connect. Die Person, die zustimmt, öffnet consent_url vor consent_expires_at. Er ist der Link für eine einzige Zustimmung: Senden Sie ihn nur an diese Person. Ein Lesezugriff auf die Verbindung trägt ihn nie.

  • ConnectionError — erforderlich: code, message, at

    Warum eine Verbindung nicht funktioniert. Die Meldung ist ein fester Satz plus, bei Microsoft, der AADSTS-Code; sie wiederholt nie einen Text, den ein Aufrufer gesendet hat.

  • ConnectionList — erforderlich: items, next_cursor
  • ConnectionPatch — erforderlich: none
  • ConnectionSecret — erforderlich: set, hint

    Wie eine Antwort das Secret, den Schlüssel oder das Aktualisierungs-Token einer Verbindung zeigt. Der Wert wird nie zurückgegeben.

  • ConnectionTest — erforderlich: at, ok, checks
  • ConnectionWrite — erforderlich: provider, mode, name
  • CreatedProject — erforderlich: project, organization
  • CreditPurchase — erforderlich: id, status, amount_cents, credits, credited
  • DashboardAgentAction — erforderlich: project_id
  • DashboardApplicationPreviewLaunch — erforderlich: release_id, launch_url, expires_at
  • DashboardApplicationSummary — erforderlich: count
  • DashboardBalance — erforderlich: credit_remaining, credit_included, credit_reset
  • DashboardBoot — erforderlich: none

    Eine Anfrage für die Dashboard-Shell. Jedes Mitglied ist der Body, mit dem die genannte Route für genau diese Sitzung antwortet, und fehlt, wenn diese Route dafür nicht mit 2xx antworten würde. advertising_network ist null, wenn das Projekt kein Netzwerk hat.

  • DashboardDisplayName — erforderlich: none

    Gekürzter druckbarer Anzeigename, höchstens 80 UTF-8-Bytes. Steuert Steuerzeichen, URL-ähnlichen Text, @, www., :// und Anmeldeinformationen ab. Keine Autorisierung.

  • DashboardEmail — erforderlich: email, email_verified, email_revision

    Die eigene E-Mail-Ansicht des aktuellen Benutzers. Die verifizierte Adresse bleibt wirksam, während eine Änderung aussteht, und der ausstehende Kandidat ist nur für den Eigentümer sichtbar.

  • DashboardEmailVerificationAccepted — erforderlich: status
  • DashboardHealthSummary — erforderlich: display_disconnected, hot, crashing, stale

    Aktive Bildschirme mit Gesundheitsbericht, gezählt nach Zustand; ein Bildschirm kann in mehreren zählen. display_disconnected, hot und crashing zählen nur Online-Bildschirme, deren letzter Bericht aktuell (nicht veraltet) ist; stale zählt Online-Bildschirme, deren Bericht älter als 35 Minuten ist und sonst nichts.

  • DashboardMe — erforderlich: user_id, display_name, email, password, passkeys, created_at
  • DashboardMediaSummary — erforderlich: count, bytes

    Zähler für fertige Medien im Projekt der Sitzung. bytes zählt nur gespeicherte Medienbytes; es ist nicht die Gesamtsumme used_bytes des Projekts, die auch Release-Bäume und Schlüssel/Wert-Einträge umfasst. image_bytes, video_bytes und audio_bytes teilen bytes nach Primitiv auf und ergeben immer bytes, solange image, video und audio die einzigen Primitive sind; wird jemals ein anderes Primitiv gespeichert, ergeben die drei zusammen weniger als bytes.

  • DashboardMember — erforderlich: user_id, display_name, joined_at, passkeys, password, owner, external
  • DashboardMemberList — erforderlich: items, viewer_user_id, viewer_is_owner
  • DashboardPasskey — erforderlich: id, name, credential_id, provider, created_at, last_used_at
  • DashboardPasskeyAssertion — erforderlich: ceremony_id, request_options
  • DashboardPasskeyAssertionComplete — erforderlich: ceremony_id, credential
  • DashboardPasskeyComplete — erforderlich: ceremony_id, credential
  • DashboardPasskeyList — erforderlich: rp_id, user_handle, items
  • DashboardPasskeyPatch — erforderlich: name
  • DashboardPasskeyProof — erforderlich: type, ceremony_id, credential
  • DashboardPasskeyRegistration — erforderlich: ceremony_id, creation_options
  • DashboardPasswordLogin — erforderlich: email, password
  • DashboardPasswordProof — erforderlich: type, password
  • DashboardPasswordSet — erforderlich: password, proof
  • DashboardPendingEmail — erforderlich: email, expires_at
  • DashboardProject — erforderlich: status, created_at, email, screen_count, screen_limit, used_bytes, reserved_bytes, content_limit_bytes, event_retention_days, name

    Status, Kontaktadresse, durchgesetzte Limits, Nutzung, Aufbewahrung und öffentlicher Gesamtkreditstatus für ein Projekt. Die interne Plan-ID bleibt unveröffentlicht.

  • DashboardProjectList — erforderlich: items
  • DashboardProjectListItem — erforderlich: id, name, last_used_at
  • DashboardProjectReference — erforderlich: id, name
  • DashboardProjectSwitch — erforderlich: project_id
  • DashboardProof — erforderlich: none
  • DashboardProofRequest — erforderlich: proof
  • DashboardReauthentication — erforderlich: ceremony_id, options
  • DashboardReauthenticationRequest — erforderlich: kind
  • DashboardSSOProof — erforderlich: type

    Nachweis durch eine kürzliche Single-Sign-on-Anmeldung. Er gilt, solange sich die aktuelle Sitzung vor höchstens 10 Minuten über den Identitätsanbieter der Organisation angemeldet hat, und führt weder eine Zeremonie noch ein Secret mit. Andernfalls antwortet die Route mit reauthentication_required, und die Person meldet sich erneut über ihren Anbieter an (POST /api/session/sso-starts, intent reauth).

  • DashboardScreenSummary — erforderlich: total, online, pairing_pending, active, archived

    Bildschirmzähler für das Projektsitzung. total ist pairing_pending plus aktiv und schließt archivierte aus, die zum Projekt screen_count passen. online wird aus Live-Paired-Laufzeit-Ereignisströmen genau wie Screen.online abgeleitet; es ist kein gespeichertes Boolean und kein Player-Herzschlag.

  • DashboardSession — erforderlich: user_id, display_name, email, project, auth_method, authenticated_at, expires_at, dev_auth, staff, shadow, passkey_enrollment_required, email_verification_required

    Personensitzung. Bezeichner sind beschreibend; das Sitzungscookie stellt die Autorität her. Eine Person ohne Projekte hat project: null.

  • DashboardSessionOrganization — erforderlich: id, name, managed

    Die Heimatorganisation der Person.

  • DashboardSessionSSO — erforderlich: organization_id, provider_name, linked

    Der Single-Sign-on-Kontext der Person. Vorhanden, sobald die verifizierte Adresse der Person an einer Domain liegt, deren Organisation eine Identitätsanbieter-Verbindung hat; linked ist false, bis sich die Person darüber anmeldet oder sie verknüpft. Eine SSO-Sitzung gilt 24 Stunden ab der Anmeldung und wird durch Nutzung nicht verlängert.

  • DashboardStaffWriteMode — erforderlich: request_id, project_id, expires_at
  • DashboardSummary — erforderlich: screens, media, applications
  • DeletedProject — erforderlich: id, screens, paired_screens_active, paired_screens_archived, paired_screens_completed_pending, agents, media, applications, playlists, memberships
  • DemoRequestInput — erforderlich: email, country, screen_range, organization, budget, timezone, source, flow_id
  • DemoResult — erforderlich: route, booking, review_requested, video_url, email, country, timezone, flow_id, source
  • DemoSlots — erforderlich: slots, timezone
  • DemoSource — erforderlich: none
  • DeviceSessionRequest — erforderlich: none

    Cookie-gekoppelter Browser-Mint. Der Body ist optional. Unbekannte Mitglieder werden ignoriert (docs/player-compatibility.md §1.1).

  • DisplayWindow — erforderlich: days
  • DocsPage — erforderlich: url, title, markdown, truncated, sections, corpus_commit
  • DocsSearchResponse — erforderlich: results, corpus_commit
  • DocsSearchResult — erforderlich: url, title, section, snippet, score
  • EducationEligibilitySource — erforderlich: none

    Wer education_eligible entschieden hat. staff ist eine Entscheidung der Mitarbeiter, in beide Richtungen, und endgültig. school_email ist die automatische Entscheidung aufgrund der verifizierten K-12-Schul-E-Mail-Adresse eines Admins (eine Schuldomain wie k12.ca.us oder sch.uk; niemals eine allgemeine Bildungsdomain wie .edu oder .ac.uk). Die leere Zeichenfolge bedeutet, dass niemand entschieden hat.

  • EmailVerifyRequest — erforderlich: token
  • EmailVerifyResult — erforderlich: purpose, status
  • EmptyPaymentRequest — erforderlich: none
  • EnrollmentInvitation — erforderlich: id, status, expires_at
  • Event — erforderlich: cursor, type, severity, message, at
  • EventActor — erforderlich: user_id, display_name

    Dashboard-Benutzer, der diese Mutation verursacht hat. Optional und bei jedem Ereignis, das von einem Agenten, der CLI, einem Player oder einem Worker erzeugt wurde, abwesend, sodass das Feld eine Dashboard-Mutation unterscheidet, anstatt allen Traffic zu kennzeichnen. Es ist nur eine beschreibende Zuordnung und niemals eine Autorisierung. display_name ist der Name, den der Benutzer bei der Registrierung gewählt hat und nicht verifiziert ist.

  • EventAgent — erforderlich: agent_id, name, agent_type

    Sichere Agenten-Hauptattribution nur, wenn das Ereignis direkt durch einen authentifizierten Agenten-Bearer verursacht wurde. Es ist niemals eine Autorisierung.

  • EventCommand — erforderlich: name, method

    Die Agentenanfrage, die dieses Ereignis verursacht hat. Optional und bei jedem Ereignis, das ein Dashboard-Benutzer, ein Player oder ein Worker erzeugt hat, nicht vorhanden. Sie dient nur der beschreibenden Zuordnung und ist niemals eine Autorisierung. Jedes Feld wird vom Server aus der Route, die es abgeglichen hat, oder aus dem Problemregister geschrieben.

    Ein Befehlsobjekt kann keinen Argumentvektor, keinen Anfragetext, keinen Header oder beliebigen Text des Aufrufers enthalten, und es gibt absichtlich kein Feld dafür. Name und Methode erscheinen bei jedem Ereignis, das eine Agentenanfrage auslöst.

    Die Ergebnisfelder erscheinen NUR bei einem agent.command-Ereignis, das der Datensatz für eine Anfrage ist, die kein Domain-Ereignis ausgelöst hat: Ein ausgelöstes Domain-Ereignis ist selbst der Beweis, dass die Anfrage erfolgreich war.

  • EventList — erforderlich: items, next_cursor
  • FeedDocument — erforderlich: schema, fetchedAt, attribution
  • FeedPending — erforderlich: key, state, retry_after_seconds
  • FeedbackContext — erforderlich: none

    Geschlossener Diagnoseumschlag. Jedes Mitglied ist ein optionaler eingeschränkter Skalar, Verschachtelung ist strukturell unmöglich, unbekannte Mitglieder werden mit invalid_request abgelehnt. Die Form existiert, damit ein Client keine Argumentwerte, Anmeldeinformationen oder freie Umgebungsdaten darin speichern kann.

  • FeedbackList — erforderlich: items
  • FeedbackReplyWrite — erforderlich: text
  • FeedbackResponse — erforderlich: id, text, status, created_at

    Eine unveränderliche Antwort von Personal oder Agent. Ein abwesender Autor kennzeichnet eine Antwort des Personals. Klartext (für jeden Anzeige-Kontext escapen); Anmeldeinformationen-ähnlicher Text wird vor der Speicherung durch [redacted] ersetzt.

  • FeedbackStatus — erforderlich: none

    Wo das Personal zu einer Einreichung steht. waiting_on_user fordert vom einreichenden Agenten Informationen an; eine Agentenantwort öffnet sie wieder oder einen geschlossenen Bericht. Ein „geplanter“ Bericht behält seinen Status.

  • FeedbackSubmission — erforderlich: id, kind, title, body, created_at

    Eine projektspezifische Einreichung. Ihre eigenen Felder (id, Art, Titel, Inhalt, Kontext, created_at) ändern sich nach dem Schreiben nie. Status ist offen, bis das Personal antwortet, und dann der Status der letzten Antwort; Agentenantworten öffnen Berichte, die auf Eingaben warten oder geschlossen sind, während ein „geplanter“ Bericht seinen Status behält.

    Antworten sind Mitarbeiter- und Agentenantworten, älteste zuerst und höchstens 20, niemals bearbeitet oder entfernt. Jede Antwort fügt auch ein feedback.responded-Ereignis zum Ereignisstrom des Projekts hinzu (resource.id ist die Einreichungs-ID; Details enthalten response_id, status, fixed_in und Autor für Agentenantworten, niemals den Text).

    Die Übermittlungs-ID ist niemals eine Autorisierung: nur das zugehörige Projekt liest sie.

  • FeedbackWrite — erforderlich: title, body
  • FleetLinkPatch — erforderlich: none
  • FleetLinkWrite — erforderlich: label
  • GroupBinding — erforderlich: binding_id, group_id, group_name, role, created_at
  • GroupBindingCreate — erforderlich: group_id, role
  • GroupBindingGroup — erforderlich: id, display_name, member_count
  • GroupBindingList — erforderlich: bindings, groups
  • HLSStreamSource — erforderlich: protocol, url
  • HealthResponse — erforderlich: status
  • HealthTrend — erforderlich: items, next_cursor
  • HealthTrendHour — erforderlich: hour, screens_reporting, hot, display_disconnected, crashing
  • HostContext — erforderlich: platform

    Die Shell und Hardware, auf der ein Player läuft, wie vom Player gemeldet. Ein HINWEIS, der ein Gerät benennt; niemals eine Anmeldeinformation, niemals eine Autorisierung. Nur der Ed25519-Schlüssel autorisiert.

    Pro Bildschirm gespeichert, ersetzt durch jede Sitzungsmünze, die eine enthält, mit dem Bildschirm gelöscht, nie in Betriebsprotokollen geschrieben, nie in Problemantworten wiedergegeben und nie an ein anderes Projekt als das des Eigentümers zurückgegeben. Nur lesbar über die Projekt-API; ScreenPatch kann es nicht schreiben.

  • HostDevice — erforderlich: none

    Optionale Hardware-IDs. duid und serial sind die einzigen zwei, die der Wiederherstellungshinweis konsultiert; ein fehlgeschlagenes Lesen am Player lässt das Feld weg.

  • IceServer — erforderlich: urls

    Ein RTCIceServer. URLs mit Port 53 werden entfernt, weil Browser sie blockieren und nichts getrickelt wird.

  • IdentityProvider — erforderlich: connection_id, kind, preset, name, jit, service_provider, ready_to_require, policy, revision, created_at, updated_at

    Die Single-Sign-on-Verbindung der Organisation. Sie enthält kein Secret.

  • IdentityProviderCertificate — erforderlich: sha256, subject, not_after
  • IdentityProviderOIDC — erforderlich: issuer, client_id, client_secret_set, scopes
  • IdentityProviderOIDCWrite — erforderlich: client_id
  • IdentityProviderSAML — erforderlich: idp_entity_id, idp_sso_url, certificates
  • IdentityProviderSAMLWrite — erforderlich: none
  • IdentityProviderServiceProvider — erforderlich: oidc_redirect_uri, saml_entity_id, saml_acs_url, saml_metadata_url

    Die Werte, die beim Identitätsanbieter einzutragen sind, abgeleitet vom Dashboard-Origin und der ID der Verbindung.

  • IdentityProviderTest — erforderlich: at, ok, subject_present

    Das Ergebnis der letzten Test-Anmeldung über die Verbindung.

  • IdentityProviderWrite — erforderlich: kind, preset, name, proof
  • Invitation — erforderlich: id, kind, delivery, status, project_id, created_at, expires_at
  • InvitationAcceptRequest — erforderlich: token, mode

    Neue Anmeldeinformationen sind für create_login und reset erforderlich. Link create_login benötigt das verifizierte Signup-Cookie und verwendet dessen Anzeigenamen und E-Mail.

    E-Mail create_login erfordert display_name. signed_in benötigt eine Anmeldung innerhalb von zehn Minuten oder einen invitation_accept-Nachweis, der an die Einladungs-ID gebunden ist. buyer gilt nur für ad_buyer; neue Käuferprojekte starten mit null Guthaben.

  • InvitationAccepted — erforderlich: kind, project_id, next
  • InvitationAdvertising — erforderlich: screen_ids, slot_ids, policy

    Vom Verkäufer besetzter Bereich: mindestens ein Bildschirm oder Slot. Nur Bildschirme, nur Slots oder beides sind akzeptiert.

  • InvitationBuyer — erforderlich: none
  • InvitationCreate — erforderlich: kind

    E-Mail-Zustellung erfordert E-Mails. Link-Zustellung ist nur project_member und lässt E-Mails und Werbung weg. ad_buyer erfordert Werbung. Maximal 50 ausstehende Mitglieder- und Käufer-Einladungen pro Organisation; eine ausstehende E-Mail-Einladung desselben Typs und derselben Adresse wird wiederverwendet.

  • InvitationCreated — erforderlich: invitations
  • InvitationCredential — erforderlich: none
  • InvitationEmailVerificationAccepted — erforderlich: status, expires_at
  • InvitationEmailVerificationRequest — erforderlich: token, display_name, email
  • InvitationInspect — erforderlich: id, kind, delivery, project, expires_at, person, modes, methods

    Nicht verbrauchende Inspektion. person ist null für Links. Meldet niemals den Anmeldestatus, außer dass ein Anmelde-Reset, dessen Link nur an die Adresse ging, angibt, ob sein Abschluss ein nicht verifiziertes Konto ersetzt (replaces_unverified_account). E-Mail-Modi sind create_login oder signed_in; Links bieten beide, und Resets bieten reset.

  • InvitationInspectRequest — erforderlich: token
  • InvitationIssued — erforderlich: id, kind, delivery, status, project_id, created_at, expires_at
  • InvitationKind — erforderlich: none
  • InvitationList — erforderlich: items, next_cursor
  • InvitationPasskeyOptionsRequest — erforderlich: token, mode
  • InvitationPasswordCredential — erforderlich: type, password
  • InvitationSignup — erforderlich: email, display_name, verified, expires_at
  • InvitationStatus — erforderlich: none
  • KVEntry — erforderlich: application_id, key, value_base64, content_type, bytes, sha256, revision
  • KVList — erforderlich: items, next_cursor
  • KVSummary — erforderlich: application_id, key, content_type, bytes, sha256, revision
  • KVWebhook — erforderlich: id, application_id, key, description, url, created_at

    Ein eingehender Key/Value-Webhook. Sein Geheimnis wird nur bei create und rotate-secret zurückgegeben.

  • KVWebhookCreate — erforderlich: key
  • KVWebhookDelivery — erforderlich: at, outcome, status, bytes, request_id
  • KVWebhookDeliveryList — erforderlich: items
  • KVWebhookList — erforderlich: items
  • KVWebhookWithSecret — erforderlich: none
  • KVWebhookWriteResult — erforderlich: key, revision, bytes, sha256, content_type, updated_at
  • KVWrite — erforderlich: value_base64
  • LevelDate — erforderlich: date

    Ein bestimmtes ziviles Datum, der ganze Tag oder zwischen start und end wie bei einem Fenster. Es beginnt zwischen from und until und ist kein Ausnahmedatum.

  • LevelInteraction — erforderlich: none

    Die Ebene gilt, solange jemand den Bildschirm nutzt: ab einer Berührung, einem Klick oder einer Taste, bis idle_s Sekunden ohne Eingabe vergehen. Typische Verwendung: eine interaktive Seite über einer Attract-Schleife. idle_s wird gespeichert und zurückgegeben (60, wenn ausgelassen).

  • LevelMonthly — erforderlich: none

    Ein monatliches Vorkommen in der Zeitzone des Bildschirms: day (1 bis 31; ein Monat ohne diesen Tag wird übersprungen) oder nth (1 bis 4, -1 der letzte) und weekday. start und end wie bei einem Fenster; das Datum, an dem das Vorkommen beginnt, gehört ihm.

  • LinearGradientBackground — erforderlich: type, stops

    Linearer Farbverlauf von oben nach unten. Es gibt kein Winkel-Feld. stops hat 2 bis 8 Einträge, streng steigend bei in [0, 1], erster bei=0, letzter bei=1.

  • LinearGradientStop — erforderlich: at, color

    Ein Stopp auf einem von oben nach unten verlaufenden linearen Leinwand-Hintergrund. at=0 ist die obere Kante, at=1 die untere Kante.

  • LiveFrames — erforderlich: live_id, state

    Fortschritt des Frame-Adapters einer Live-Sitzung. Offenes Schema.

  • LiveSession — erforderlich: state, screen_id, viewer_url

    Live-Sitzung eines Bildschirms. Offenes Schema.

  • LiveStartRequest — erforderlich: none
  • LiveViewer — erforderlich: viewer_id, live_id, offer, ice_servers, expires_at

    Das Relay-Angebot eines Betrachters. Offenes Schema.

  • LiveViewerAnswer — erforderlich: answer
  • ManifestActivatedContext — erforderlich: manifest_revision
  • ManifestActivatedReport — erforderlich: severity, code, context
  • ManifestUpgradeContext — erforderlich: manifest_revision, state
  • ManifestUpgradePlaylist — erforderlich: id, name, revision

    Die Playlist-Identität hinter einer ausgegebenen oder in der Warteschlange stehenden gewünschten Revision: desired_playlist verwendet seine genaue gewünschte Berechtigung oder das schreibgeschützte geteilte Inhaltsziel für die aktuelle wirksame Zuweisung vor der Berechtigungsausgabe. active_playlist verwendet immer die exakt anerkannte historische Berechtigung, niemals eine neuere Zuweisung oder Inhaltsbearbeitung. ID plus Revision sind die Playlist-Version, die ein Operator als Ziel v42 / Wiedergabe v41 liest; name ist der Anzeigename der Playlist, null, wenn die Playlist nicht mehr existiert oder nicht aufgelöst werden kann.

    Ein fehlender historischer aktiver Grant ist null, niemals eine erfundene Revision. Ein in der Warteschlange stehendes gewünschtes Ziel gewährt keinen Inhaltszugriff.

  • ManifestUpgradeReport — erforderlich: severity, code, context

    Ein Latest-Wins Manifest-Upgrade-Lebenszyklus-Snapshot für den Sitzungsschirm.

    Der Server speichert einen Slot pro Bildschirm und leitet daraus das Projekt-Lesemodell Screen.manifest_upgrade ab; ein veralteter, ersetzter oder vor der Aktivierung nach der Aktivierung gemeldeter Bericht wird ohne Änderung akzeptiert (202), nie als Konflikt abgelehnt, und kein Bericht fördert jemals eine Berechtigung. severity ist nur für den Umschlag: die abgeleitete Projekt-Ereignis-Schwere stammt vom Zustand.

  • McrString — erforderlich: none

    Exakte ganze Millicredit-Menge als kanonische Dezimalzeichenfolge. 1 Credit entspricht 1000 mcr.

  • Media — erforderlich: id, filename, primitive, content_type, operation_id, sha256, bytes, revision, state, created_at, updated_at
  • MediaAvailability — erforderlich: none

    Wann dynamische Selektoren die Medien auswählen dürfen, in der Zeitzone jedes Bildschirms: innerhalb von [from, until) und an einem Vorkommen von windows, monthly oder dates (keines der drei: jeden Tag), dessen Datum nicht in except steht. Die Ebenengrammatik des Zeitplans ohne data und interaction.

  • MediaAvailabilityPatch — erforderlich: availability
  • MediaCommit — erforderlich: content_type, bytes, sha256

    Deklariert nur, was der Server byteweise gegen das gespeicherte Objekt erneut überprüfen kann. Die Codec-Identität wird hier nicht deklariert: Der Server leitet sie während der asynchronen Verifizierung aus dem Container ab, sodass ein Client keinen Codec angeben kann, der das Player-Verhalten steuert.

  • MediaFolder — erforderlich: id, name, parent_id, revision, created_at, updated_at

    Ein Medienbibliotheksordner. Ein Playlist-Selektor nach:Ordner spielt die bereitgestellten Dateien direkt darin ab, nicht die seiner Unterordner.

  • MediaFolderCreate — erforderlich: name
  • MediaFolderList — erforderlich: items
  • MediaFolderPatch — erforderlich: none
  • MediaGenerationReference — erforderlich: none

    Genau eines von media_id oder b64. HTTP-URLs werden abgelehnt.

  • MediaGenerationRequest — erforderlich: prompt

    Fordert ein Standbild an. Der Prompt sind Kundendaten und wird nie zurückgegeben, protokolliert oder im Projekt-SSE veröffentlicht. aspect_ratio standardmäßig 16:9. Qualität ist niedrig, mittel oder hoch und standardmäßig mittel. tag wird wie ein Upload-Tag im bereiten Medienobjekt gespeichert. Optionale Referenzen sind Inline-Base64 oder eine Projekt-media_id; HTTP-URLs werden abgelehnt.

    Die summierte Größe aller Referenzen einer Anfrage, sowohl inline als auch media_id, darf 25.165.824 Bytes (24 MiB) nicht überschreiten; eine Anfrage über diesem Limit wird abgelehnt.

    Bei Standard führt ein Guthaben, das nach dem Einführungsniveau (minus 1.000.000 Credits bis 2027-01-01, dann null) nicht die doppelten Anbieterkosten des Standbilds abdeckt, auf ganze Credits aufgerundet, zu payment_required, außer in der Entwicklung. Andere Pläne werden nie wegen ihres Guthabens abgelehnt.

  • MediaGenerationUsage — erforderlich: quality, credits, usd

    Kundenbezogener Debit für ein gespeichertes Standbild, die usage im result einer Operation media.generate mit succeeded. Qualität ist die angeforderte Qualität und ändert das Bild, kein Festpreis. Guthaben sind das Doppelte der Lieferantenkosten dieses Standbilds, aufgerundet auf ganze screenRIG-Guthaben. USD ist der Dollarwert dieser Guthaben.

    Niemals ein Lieferantenname, Lieferantenkosten oder Tokenanzahl.

  • MediaList — erforderlich: items
  • MediaMove — erforderlich: folder_id

    Mindestens eine ID aus media_ids und folder_ids, höchstens 1000 insgesamt.

  • MediaMoveResult — erforderlich: media, folders
  • MediaReplace — erforderlich: upload_id
  • MediaRestore — erforderlich: none
  • MediaRestorePending — erforderlich: status, review, warnings
  • MediaRestored — erforderlich: media, warnings
  • MediaSelectorTagFilter — erforderlich: none
  • MediaSelectorWeights — erforderlich: none

    Anteile eines gewichteten Selektors, geordnet nach Medien-ID oder tag:NAME.

    Das Gewicht eines Elements ist sein Medien-ID-Schlüssel, falls vorhanden; sonst der alphabetisch erste Schlüssel tag:NAME unter den Tags, die es trägt, wobei dieses Gewicht gleichmäßig auf die Elemente der Auswahl verteilt wird, die ihn tragen, sodass der Anteil eines Sponsors unabhängig von der Anzahl seiner Creatives gleich bleibt; sonst zählt das Element als eigene Gruppe mit Gewicht 1.

    Jeder vollständige Zyklus spielt jedes Element genau mit seinem Anteil ab.

  • MediaSingleTagPatch — erforderlich: tag
  • MediaSync — erforderlich: id, project_id, account_id, provider, name, folder_id, every_s, state, source, next_run_at, revision, created_at, updated_at

    Ein Quellordner, der mit einem Medienordner abgeglichen wird.

  • MediaSyncAccount — erforderlich: id, project_id, kind, name, config, secret, state, revision, created_at, updated_at

    Worüber Synchronisierungen lesen: die Zugangsdaten der eigenen Microsoft-Entra-App des Projekts (microsoft365), die Verbindung einer Person zu Canva (canva) oder Dropbox (dropbox) oder ein Google-Dienstkonto, für das Ordner freigegeben sind (google_drive). Das Client-Secret, die Token und der Schlüssel werden versiegelt und nie zurückgegeben.

  • MediaSyncAccountConfig — erforderlich: none
  • MediaSyncAccountConnect — erforderlich: none

    Ein Konto, das mit seinem einmaligen Zustimmungslink beantwortet wird: So antworten das Anlegen eines Canva- oder Dropbox-Kontos und media sync account connect. Die Person, der das Canva- oder Dropbox-Konto gehört, öffnet authorize_url vor authorize_expires_at, bei Canva oder Dropbox angemeldet. Er ist der Link für eine einzige Zustimmung: Senden Sie ihn nur an diese Person. Lesezugriffe auf das Konto tragen ihn nie.

  • MediaSyncAccountList — erforderlich: items, next_cursor
  • MediaSyncAccountPatch — erforderlich: none
  • MediaSyncAccountWrite — erforderlich: kind, name
  • MediaSyncCheck — erforderlich: name, ok, detail
  • MediaSyncDesign — erforderlich: id, title

    Ein Canva-Design, das die verbundene Person sehen kann.

  • MediaSyncDesignList — erforderlich: items, continuation
  • MediaSyncList — erforderlich: items, next_cursor
  • MediaSyncPatch — erforderlich: none
  • MediaSyncRun — erforderlich: at, status, added, updated, removed, pending_delete, skipped_total

    Die Zusammenfassung des letzten Laufs einer Synchronisierung.

  • MediaSyncRunError — erforderlich: code, detail
  • MediaSyncSecret — erforderlich: set, hint

    Wie eine Antwort das Client-Secret eines Kontos, die Token eines Canva- oder Dropbox-Kontos (set, sobald verbunden, ohne hint) oder den eigenen Dienstkonto-Schlüssel eines Google-Drive-Kontos (set, wenn das Konto einen hat; hint sind die letzten vier Zeichen seiner private_key_id) anzeigt. Der Wert wird nie zurückgegeben.

  • MediaSyncSkipped — erforderlich: name, reason
  • MediaSyncSource — erforderlich: web_url

    Die Quelle, die eine Synchronisierung liest, aufgelöst beim Anlegen der Synchronisierung. Ein SharePoint-Ordner hat drive_id und item_id; ein Dropbox-Ordner item_id und path; ein Google-Drive-Ordner item_id, drive_id, wenn er sich in einer geteilten Ablage befindet, und shared_by; ein Canva-Design hat design_id und die darauf folgenden Mitglieder.

  • MediaSyncTest — erforderlich: at, ok, checks
  • MediaSyncWrite — erforderlich: provider, account_id
  • MediaTagPatch — erforderlich: none
  • MediaTagsPatch — erforderlich: tags
  • MediaUploadDeclaration — erforderlich: filename, content_type, bytes, sha256

    Deklariert einen Upload. Die maximale Byte-Anzahl ist eine pläneunabhängige Transportobergrenze, keine erreichbare Größe. Ein Bild-Medientyp ist zusätzlich auf 20.971.520 Bytes (20 MiB) begrenzt, und eine größere Bilddeklaration wird mit invalid_request abgelehnt, bevor Bytes übertragen werden.

    Diese Bildgrenze ist ein reines Byte-Tor: Die Deklaration dekodiert das Bild nie, um dies durchzusetzen, und sie gilt für animierte GIFs und animierte WebP genauso wie für ein Standbild. Der Standardplan hat keine Speicherbegrenzung für Produkte.

    Ein benutzerdefiniertes Speicherlimit wird, sofern vorhanden, zuerst geprüft, und eine Deklaration, die es nicht aufnehmen kann, wird mit quota_exceeded zurückgewiesen, bevor ein Byte übertragen wird.

    Ein Standard-Projekt ohne Guthaben wird bei declare und commit mit payment_required abgelehnt, wenn die Bytes, die sein Zahler speichert, mit diesem Upload 1000000000 Bytes (1 GB, der kostenlose Speicher von Standard) überschreiten; Bandbreite wird nie berechnet.

    Eine audio/mpeg (MP3)-Deklaration ist auf 178257920 Bytes, 170 MiB, begrenzt, eine größere wird ebenso abgelehnt; lesen Sie media_audio_bytes zum Vorprüfen.

    Eine video/mp4- oder video/webm-Deklaration ist durch den Plan des Projekts begrenzt, auf 500000000 Bytes, 500 MB, bei Standard und auf 1000000000 Bytes, 1 GB, bei jedem anderen Plan, eine größere wird ebenso abgelehnt und nennt die geltende Grenze; lesen Sie media_video_bytes aus GET /api/project/capabilities zum Vorprüfen.

    Ein Planwechsel betrifft nur spätere Deklarationen: gespeicherte Videos werden weiter abgespielt. Lesen Sie media_image_bytes aus dem Fähigkeitsdokument zum Vorprüfen der Bildgrenze und project_content_bytes dort oder content_limit_bytes im Projekt, um eine benutzerdefinierte Speicherobergrenze zu kennen. Ein optionales Tag wird auf dem bereiten Medienobjekt gespeichert und bei Commit nicht erneut deklariert.

    Ein optionaler source_filename speichert den ursprünglichen Dateinamen des Aufrufers, wenn der Client die Bytes vor dem Upload transkodiert hat; der Dateiname des bereiten Objekts wird dann davon abgeleitet, sodass sich unterschiedliche Quellen nie überschneiden (photo.png, hochgeladen als photo.webp, wird als photo.png.webp gespeichert, photo.jpg als photo.jpg.webp, und eine Quelle photo.webp bleibt photo.webp).

  • MediaUploadSession — erforderlich: id, operation, upload_url, method, headers, expires_at
  • MediaUploadSource — erforderlich: filename, content_type, sha256, bytes

    Verifizierte ursprüngliche Upload-Identität bei der Verarbeitung normalisierter EXIF-Orientierung. Nur lesbar; verwenden Sie sie, um Wiederholungen zu erkennen. Der fertige Medien-Digest, Größe und Typ beschreiben die normalisierten Übertragungsbytes.

  • MediaUsage — erforderlich: playlists, screens
  • MediaUsagePlaylist — erforderlich: id, name, uses, screen_count
  • MediaUse — erforderlich: kind, where

    Eine Art, wie eine Playlist die Mediendatei enthält oder erreicht; eine Playlist, die das auf mehreren Seiten tut, zählt als eine Verwendung.

  • MediaVersion — erforderlich: number, current, filename, content_type, sha256, bytes, source, created_at
  • MediaVersionActor — erforderlich: kind
  • MediaVersionPage — erforderlich: items, next_cursor
  • MediaWarning — erforderlich: code, detail, playlists
  • MediaWarningPlaylist — erforderlich: id, name
  • MemberActivity — erforderlich: id, project_id, user_id, display_name, at, kind, action, outcome, status, source
  • MemberActivityClient — erforderlich: kind

    Der Client, wie er im Edge-Anforderungsprotokoll genannt wird, geparst aus User-Agent und Sec-CH-UA-Platform.

  • MemberActivityKind — erforderlich: none

    sign_in und sign_in_failed enthalten auth_method; credential_changed ist ein hinzugefügter, umbenannter oder entfernter Passkey, ein gesetztes Passwort oder eine angeforderte oder verifizierte E-Mail-Änderung; reauthenticated ist ein überprüfter Nachweis (Aktion reauthentication.<proof kind>); mutation ist jede andere Dashboard-Änderung.

  • MemberActivityList — erforderlich: items, next_cursor, recorded_since
  • MemberActivityOutcome — erforderlich: none

    ok bei Status unter 400, abgelehnt bei 4xx-Antwort, fehlgeschlagen bei 5xx-Antwort.

  • MemberActivityResource — erforderlich: type
  • MemberApproverUpdate — erforderlich: can_approve
  • MemberScreenScopeUpdate — erforderlich: screen_scope
  • MemberUploadScopeUpdate — erforderlich: upload_scope
  • NativeIdentityChallenge — erforderlich: nonce, expires_at, aud, op, request_hash

    Vergleichen Sie die zurückgegebenen op- und request_hash-Werte mit Ihren lokal berechneten Werten vor dem Signieren. Jeder Nonce läuft nach 120 Sekunden ab und kann nur einmal verwendet werden.

  • NativeIdentityChallengeRequest — erforderlich: kid, op, request_hash

    Geben Sie für jede Herausforderung die Operation und deren request_hash an. Ein unbekannter Schlüssel erfordert auch public_key und op=pairing.start. Das Erstellen einer Herausforderung meldet den Schlüssel nicht an.

  • NativeIdentityProof — erforderlich: kid, public_key, signature

    Kompakter JWS-geschützter Header ist genau {"alg":"EdDSA"}. Claims sind kid, nonce, aud=screenrig-runtime, op, integer iat/exp, nichtleerer jti und request_hash.

    Kontextuelle Nachweise dauern höchstens 120 Sekunden und verfallen spätestens mit der ausgestellten Herausforderung. request_hash ist der kleingeschriebene SHA-256-Hash von UTF-8-Zeichenketten, die durch ein NUL verbunden sind, ohne abschließendes NUL, beginnend mit screenrig.native.identity.request.v1 und op.

    Fügen Sie für pairing.start und session.mint den Idempotency-Key hinzu; für pairing.complete fügen Sie die exakte srp_ Kopplungsanmeldeinformation und dann completion_nonce hinzu; für identity.reset wird nichts angehängt. Jeder Nachweis muss request_hash enthalten. Ein zwischengespeichertes Operationsergebnis erfordert dennoch einen frisch ausgestellten Nachweis oder den exakt akzeptierten Nachweis, solange dessen kurzlebiger Beleg gültig ist.

    Doppelte oder unbekannte JWS/JWK-Mitglieder, nicht-kanonisches base64url und Schlüssel ohne Primzahlordnung werden abgelehnt. Unbekannte Anforderungsmitglieder im Body werden ignoriert.

  • NativeIdentitySessionRequest — erforderlich: kid, public_key, signature

    NativeIdentityProof mit op=session.mint plus optionalem Host-Hinweis. Ein vorhandener Host ERSETZT den auf dem Bildschirm gespeicherten Host, da Firmware- und Shell-Versionen im Lebenszyklus eines Bildschirms variieren. Der Hinweis beeinflusst niemals die Autorisierung; nur der signierte Nachweis tut dies.

    Unbekannte Mitglieder werden ignoriert, und Host sowie Wiedergabe werden tolerant gelesen (docs/player-compatibility.md §1.1).

  • NativePairingComplete — erforderlich: completion_nonce, public_key, signature
  • NativePairingCompletion — erforderlich: screen, public_url
  • NativePairingRecovery — erforderlich: offered

    Nur vorhanden, wenn die Host-DUID oder Seriennummer in der Startanfrage genau einem bestehenden Bildschirm entspricht, der an einen anderen Schlüssel gebunden ist. Es enthält keinen Bildschirm, keine Bezeichnung oder kein Projekt: Das Angebot wird projektseitig als Screen.recovery_pending und das screen.recovery_offered-Ereignis angezeigt, und nur das Eigentümerprojekt kann es bestätigen.

    Sie ist abwesend, genau wie ohne Übereinstimmung, wenn der Bezeichner mehrdeutig ist, wenn der Schlüssel des gefundenen Bildschirms in den letzten zehn Minuten Aktivität zeigte oder wenn dieser Bildschirm bereits drei Angebote in der rollierenden Stunde angenommen hat. Der Kopplungscode wird weiterhin genau wie ohne Übereinstimmung ausgegeben und angezeigt. Der Player verwendet dies ausschließlich, um pairing.recovery_offered zu protokollieren.

  • NativePairingSession — erforderlich: code, pairing_credential, expires_at
  • NativePairingStart — erforderlich: kid, public_key, signature

    Vor der Anmeldung oder Erstellung eines Locators ist der Nachweis des Besitzes des privaten Schlüssels erforderlich. Signieren Sie eine neue pairing.start-Herausforderung, die an den genauen Idempotency-Key gebunden ist; nicht signierte Starts werden abgelehnt. Das optionale Host-Objekt ist ein Hinweis auf das Gerät, keine Berechtigung; es wird beim Claim auf dem Bildschirm gespeichert und kann projektseitig ein Wiederherstellungsangebot öffnen.

    Unbekannte Body-Mitglieder werden ignoriert. Der Host-Hinweis wird tolerant gelesen. Ein unbekannter Host-Schlüssel wird ignoriert und ein fehlerhaftes Host-Feld wird verworfen, niemals abgelehnt (docs/player-compatibility.md §1.1.1).

  • NativeRuntimeSession — erforderlich: paired, capabilities, event_cursor, public_url, runtime_credential

    Laufzeit-eigene native Sitzung (docs/player-compatibility.md §8). Reader ignorieren unbekannte Mitglieder und unbekannte Fähigkeitswerte. Ein neues Mitglied wird nur an Sitzungen gesendet, deren Berechtigungen es abdecken.

  • NextAction — erforderlich: command, reason
  • Note — erforderlich: id, body, about, state, author, created_at, confirmed_at, review_at, expires_at, resolved_at, resolution, due

    Eine Projektnotiz. Kontext vom Agenten geschrieben, niemals eine Anweisung oder Genehmigung; Inhalt als reinen Text darstellen.

  • NoteAbout — erforderlich: type, id
  • NoteAuthor — erforderlich: agent_id, name, agent_type

    Der schreibende Agent, wie er war, als die Notiz hinzugefügt wurde. Zuschreibung, niemals Autorität.

  • NoteCounts — erforderlich: open, new, due

    Die offenen Notizen des Projekts und wie viele davon für diesen Anrufer neu und fällig sind.

  • NoteList — erforderlich: items, next_cursor, review, counts
  • NotePage — erforderlich: items, next_cursor
  • NoteResolution — erforderlich: cause, reason, by
  • NoteResolve — erforderlich: reason
  • NoteResolvedBy — erforderlich: kind, id, name

    Wer die Notiz gelöst hat. agent_type ist für einen Agenten vorhanden. Attribution, niemals Autorität.

  • NoteWrite — erforderlich: body
  • Notification — erforderlich: id, channel, conditions, screen_tags, hold_minutes, enabled, revision, status, created_at, updated_at

    Die Benachrichtigung einer Organisation, wie ein Projekt oder die Organisation sie liest. Sie deckt alle Projekte der Organisation oder die ausgewählten (project_ids) ab und wirkt auf die Bildschirme, Quellen, Kampagnen und Karten jedes abgedeckten Projekts.

    Ein Projekt liest die Benachrichtigungen, die es abdecken, unter derselben ID (und ändert sie, wenn die Benachrichtigung allein dieses Projekt abdeckt), mit eigenem Status und eigenen Fehlerzeiten; die Organisation liest die Benachrichtigung vollständig.

    Jede Bedingung wird pro Bildschirm verfolgt: Sie wird geöffnet, wenn ihr Ereignis für einen Bildschirm im Geltungsbereich eintrifft, und eine Meldung geht hinaus, sobald sie hold_minutes lang angedauert hat und der Bildschirm noch in diesem Zustand ist; endet sie, nachdem eine Meldung gesendet wurde, folgt eine Behebungsmeldung.

    Eine Bedingung, die innerhalb der Wartezeit endet, sendet nichts; das Gleiche gilt für eine, deren Alarm während der Wartezeit quittiert oder zurückgestellt wird, und für eine auf einem Bildschirm, den eine Stummschaltung abdeckt.

    E-Mail: eine E-Mail pro Empfänger für alles, was innerhalb von etwa zwei Minuten fällig wird, mit Auflistung jedes Bildschirms und jeder Bedingung sowie Links zum Bildschirm und zu dieser Benachrichtigung im Dashboard; Benachrichtigungs-E-Mails sind kostenlos.

    Jede Alarm- und Test-E-Mail enthält für die Person, an die sie adressiert ist, einen Abmeldelink (die Header List-Unsubscribe und List-Unsubscribe-Post sowie die Fußzeile), der die E-Mails dieser Benachrichtigung nur für diese Person beendet, ohne Anmeldung; siehe unsubscribed.

    Webhook: Jede Meldung wird als JSON per POST gesendet {type: alert.opened oder alert.resolved, id, notification_id, project_id, condition, screen {id, name}, since, at, event_id, severity}, wobei id die Zustell-ID ist, since der Zeitpunkt, zu dem die Bedingung begann, at der Zeitpunkt, zu dem sie lange genug galt (opened) oder endete (resolved), event_id der Cursor des zugrunde liegenden Ereignisses ist und severity (info, warning oder error) der Schweregrad der Bedingung für alert.opened und info für alert.resolved ist, bei jeder Webhook-Benachrichtigung.

    Die Meldung einer Kampagne enthält außerdem reach {published, current} (reach_dropped: die Bildschirme, die die Kampagne bei ihrer Veröffentlichung erreicht hat und beim Senden der Meldung erreicht) oder audience_group {kind: tag oder folder, value: der Tag oder die Ordner-ID} (group_empty); E-Mail und Chat sagen dasselbe in Worten.

    Eine Benachrichtigung, die min_severity oder severity setzt, nennt es außerdem in ihrem E-Mail-, Slack-, Telegram- und Teams-Text.

    Teams und PagerDuty zeigen immer den wirksamen Schweregrad. alert.resolved für screen_offline trägt außerdem likely_cause, die Ursache des beendeten Ausfalls (ScreenOutage.likely_cause) oder null, wenn unbekannt; es wartet bis zu zwei Minuten, nachdem der Bildschirm zurückgekehrt ist, auf den ersten Gesundheitsbericht, der sie bestimmt, und eine E-Mail nennt sie ebenfalls.

    Ein Neustart wird sofort bestimmt; eine Netzwerk- oder Plattformursache braucht einen Zustandsbericht, der nach der Rückkehr des Bildschirms eingeht und den ein Player bis zu 15 Minuten später senden kann. Eine Meldung, die vorher hinausging, trägt daher null, und die Ursache erscheint in ScreenOutage.likely_cause und screen.outage_classified.

    E-Mail und die Chat-Kanäle melden drei oder mehr Bildschirme, die innerhalb von fünf Minuten in dieselbe Bedingung geraten und ein Netzwerk, einen Standort, ein Modell, eine Player-Version oder ein Tag teilen, als eine Meldung mit einer Wiederherstellung (NotificationDeliveryGroup); die Meldungen der übrigen Bildschirme werden als grouped übersprungen.

    Ein Webhook sendet weiterhin eine Meldung pro Bildschirm. event_types werden als dasselbe JSON-Objekt per POST gesendet, das GET /api/events liefert.

    Jeder POST enthält ScreenRig-Webhook-Id (die ID der Benachrichtigung), ScreenRig-Event-Id (die Zustellungs-ID bei einer Meldung, der Ereignis-Cursor bei einem Ereignis; über Wiederholungen hinweg stabil, deduplizieren Sie darüber), User-Agent und ScreenRig-Signature t=<unix seconds>,v1=<hex HMAC-SHA256 over "<t>.<raw body>" keyed with the secret string>.

    Eine 2xx-Antwort innerhalb von 10 Sekunden gilt als Erfolg; alles andere wird 24 Stunden lang mit exponentiellem Backoff wiederholt (ab 30 Sekunden, jeweils verdoppelt bis auf eine Stunde, mit Jitter) und gilt danach als fehlgeschlagen; fehlgeschlagene E-Mails werden auf dieselbe Weise wiederholt.

    Bildschirmmeldungen und screen.*-Ereignisse sind kostenlos; andere Ereignisse werden wie ein listen-stream-Ereignis abgerechnet. status ist failing, solange seit failing_since nichts erfolgreich war; nach 72 Stunden ununterbrochener Fehler wird die Benachrichtigung deaktiviert (disabled_reason delivery_failures) und notification.disabled wird angehängt.

  • NotificationActiveHours — erforderlich: timezone, windows

    Wann geöffnete Meldungen hinausgehen: die Fenster (screenrig.schedule/v1), gelesen in timezone. Eine Meldung, die fällig wird, während sie geschlossen sind, wartet auf das nächste Öffnen (outside hold, der Standard) und geht dann hinaus, wenn ihre Bedingung noch gilt, sodass eine Bedingung, die vorher endet, nichts sendet, oder wird übersprungen (outside drop; last_error outside_hours).

    Eine behobene Meldung zu einer gesendeten geöffneten Meldung geht immer hinaus, innerhalb der Zeiten oder nicht, und ein Test ignoriert sie. crashing wird wie jede andere Bedingung zurückgehalten oder verworfen. Die Zeiten beurteilen eine Meldung, wenn sie zum ersten Mal hinausgeht; eine fehlgeschlagene wird nach dem üblichen Zeitplan wiederholt, gleich welche Zeiten gelten.

    Das Hinzufügen, Ändern oder Entfernen der Zeiten beurteilt die für die alten Zeiten zurückgehaltenen Meldungen sofort neu.

  • NotificationCondition — erforderlich: none

    Eine wichtige Zustandsänderung eines Bildschirms. screen_offline: Der Player hat seine Verbindung verloren (screen.offline, 60 Sekunden nach Ablauf seiner Präsenz geschrieben); endet mit screen.online. display_disconnected: Der Player meldet, dass sein Display getrennt ist (screen.health_changed change display_disconnected); endet mit display_reconnected. running_hot: Das Gerät meldet eine Temperatur auf oder über der Hitzeschwelle (temperature_high); endet mit temperature_normal. on_battery: Das Gerät hat einen Akku, und sein letzter Gesundheitsbericht nennt als Akkuquelle none, also nicht angeschlossen (screen.health_changed change on_battery); endet, wenn ein Bericht eine andere Quelle nennt (plugged_in).

    Die Meldung besagt, dass der Bildschirm im Akkubetrieb läuft, und nennt keine Ursache. storage_full: Der Speicher des Players reicht für seine Inhalte nicht aus (screen.storage_shortfall); endet mit screen.storage_shortfall_cleared. content_stuck: Die Inhaltsaktualisierung des Bildschirms wird wiederholt, ist fehlgeschlagen, ist blockiert oder erfolgte nur teilweise (screen.manifest_upgrade); endet, wenn ein späterer Zustand keiner davon ist. not_playing: Der Player zeigt statt seiner Inhalte einen Status der Fehlerstufe (screen.status_changed mit level error, außer storage_full); endet, wenn sein Status kein Fehler mehr ist. loop_stalled: Der Player meldet nichts Auffälliges und seine Inhalte sind aktuell, doch beim Backend ist länger als die Schleife des Bildschirms erlaubt kein Mediastart eingegangen (screen.glass_changed mit dem Wiedergabeurteil stalled; Screen.glass sagt, wann es urteilt und was es auslässt); endet, wenn ein Mediastart eintrifft oder der Bildschirm nicht mehr beurteilt wird, etwa wenn er offline geht. glass_blank und glass_frozen: Das Backend hat die Screenshots des Bildschirms über einen Durchlauf gelesen, der seine Schleife abdeckt, und alle waren einfarbig (glass_blank) oder dasselbe Bild (glass_frozen) (screen.glass_changed mit dem Bildurteil blank oder frozen; Screen.glass sagt, wann es urteilt und was es auslässt); endet, wenn zwei Screenshots in Folge ein bewegtes Bild zeigen oder der Bildschirm nicht mehr beurteilt wird.

    Ein Bildschirm, der nicht mehr beurteilt wird, schließt den Alarm, aber E-Mail- und Chat-Benachrichtigungen senden dafür keine Wiederherstellungsmeldung, weil nichts als wiederhergestellt beobachtet wurde (die Behebungszeile wird als no_longer_judged übersprungen); ein Medienstart oder zwei gute Screenshots lösen eine aus. crashing: Der Player ist abgestürzt oder hat seinen Renderer wiederholt neu gestartet (screen.health_changed change crash_spike oder renderer_restart_spike); wird sofort gesendet, nie zurückgehalten und nie behoben. source_failed und source_stale betreffen eine Datenquelle, keinen Bildschirm: Das Element screen der Meldung enthält die ID und den Namen der Quelle, der Link ist die Seite der Quelle, und screen_tags stimmt nie mit einer Quelle überein, sodass eine auf Tags beschränkte Benachrichtigung sie nicht überwacht. source_failed: Eine Aktualisierung der Quelle ist fehlgeschlagen (source.status_changed mit state error); endet bei der nächsten funktionierenden Aktualisierung (state ok). source_stale: Die letzte gute Aktualisierung der Quelle ist älter als ihr Wert stale_after_seconds, der Zeitpunkt, zu dem die Kartendaten ablaufen und davon abhängige Seiten auf einen Ersatz zurückfallen (source.stale); endet bei der nächsten funktionierenden Aktualisierung.

    Keines von beiden ist ein Bildschirm-Alarm. reach_dropped und group_empty betreffen eine Kampagne (eine gemeinsame Ebene des Zeitplan-Stacks), nicht einen Bildschirm: Das Feld screen der Meldung trägt die ID und den Namen der Kampagne, der Link ist der Kalender der Kampagne im Dashboard, und eine Kampagne gehört dem Projekt, daher schränken screen_tags und audience sie nie ein. reach_dropped: Eine Neuzählung hat ergeben, dass die Kampagne weniger Bildschirme erreicht als bei ihrer letzten Veröffentlichung, weil Bildschirme einen ihrer Tags oder Ordner verlassen haben, archiviert oder gelöscht wurden (campaign.reach_changed mit current unter published); reach_drop legt fest, wie groß ein Rückgang sein muss, damit er gemeldet wird; wird behoben, wenn sie wieder so viele Bildschirme erreicht.

    Eine Veröffentlichung, die eine neue Baseline setzt, oder das Löschen der Kampagne löscht sie ebenfalls, was einen Pager-Incident und den Alarm eines Webhooks schließt, aber keine Behebungs-E-Mail und keine Chat-Meldung sendet (no_longer_judged). group_empty: Ein Tag oder Ordner der Zielgruppe der Kampagne passt auf keinen Bildschirm (campaign.group_changed mit matched 0); eine Meldung pro Tag oder Ordner (audience_group); wird behoben, wenn er wieder auf einen Bildschirm passt oder wenn eine Veröffentlichung ihn aus der Zielgruppe entfernt (removed true), was einen Pager-Incident und den Alarm eines Webhooks schließt, aber keine Behebungs-E-Mail und keine Chat-Meldung sendet (no_longer_judged).

    Die eigenen Zeitplaneinträge eines Bildschirms zielen auf Playlists, nicht auf Bildschirme, daher haben nur Kampagnen eine Reichweite.

    Keines von beiden ist ein Bildschirm-Alarm. card_data_stale betrifft eine Karte, nicht einen Bildschirm: Das Feld screen der Meldung trägt die ID der Karte und ihren Namen (den Typ der Karte, wie in „Wetterkarte“), der Link ist der Seiteneditor des Dashboards auf einer Seite, die die Karte platziert (die eigene Seite der Benachrichtigung, wenn keine das tut), und since ist der Zeitpunkt, an dem ihre Daten abgelaufen sind.

    Sie wird geöffnet, wenn das Datendokument einer Karte, das ein Agent, ein Job oder eine Person mit einem Ablauf geschrieben hat (ttl_seconds oder expires_at, wie bei card data put --ttl), diesen Ablauf erreicht, ohne dass ein weiterer Schreibzugriff es erneuert, während ein Bildschirm die Karte zeigt (card.data_expired), sodass die Karte auf diesem Bildschirm leer ist; sie wird geschlossen, wenn ein Schreibzugriff auf die Daten der Karte eintrifft (card.data_renewed).

    Die Dokumente einer Datenquelle werden nicht gemeldet: Sie laufen nach dem Ablaufzeitraum der Quelle ab, die source_stale abdeckt. Eine Karte, die kein Bildschirm zeigt, sendet nichts, und auch eine, die erneuert, gelöscht oder von allen Bildschirmen genommen wurde, bevor die Meldung fällig ist.

    Das Löschen der Daten einer Karte beendet die Meldung ohne Wiederherstellungsmeldung, so wie eine Veröffentlichung einen Reichweitenabfall beendet (no_longer_judged). Bemessen Sie ttl_seconds nach dem Zeitplan des Schreibers, damit ein angehaltener Job bemerkt wird. Wie eine Datenquelle hat eine Karte keine Bildschirm-Tags: Eine auf screen_tags beschränkte Benachrichtigung überwacht keine Karten, und sie ist kein Bildschirm-Alarm.

    Lesende Anwendungen behandeln einen unbekannten Wert als nicht vorhanden.

  • NotificationConditions — erforderlich: none
  • NotificationDelivery — erforderlich: id, notification_id, event_id, event_type, state, attempts, created_at
  • NotificationDeliveryAttempt — erforderlich: attempt, at, status, error, duration_ms
  • NotificationDeliveryAttemptList — erforderlich: items
  • NotificationDeliveryGroup — erforderlich: id, attribute, value, count

    Eine Gruppe von Bildschirmen, für die eine einzige Meldung steht. Geraten mindestens drei Bildschirme eines Projekts innerhalb von fünf Minuten in dieselbe Bedingung und teilen einen Wert, sendet eine Benachrichtigung per E-Mail, Slack, Teams, PagerDuty oder Telegram eine Meldung für alle statt einer pro Bildschirm.

    Ein Bildschirm, der später in die Bedingung gerät und einen Wert hat, aus dem die offene Gruppe besteht, schließt sich ihr ohne neue Meldung an, und eine einzige Meldung nennt die Gruppe, wenn ihr letzter Bildschirm wiederhergestellt ist. Eine Webhook-Benachrichtigung sendet weiterhin eine Meldung pro Bildschirm.

  • NotificationDeliveryList — erforderlich: items, next_cursor
  • NotificationDestination — erforderlich: none

    Nur für Slack, Teams, PagerDuty und Telegram; dort erforderlich. Die Zugangsdaten in der Form, in der der Dienst sie ausstellt: slack, die URL des eingehenden Webhooks (hooks.slack.com); teams, die URL des Workflows-Webhooks (logic.azure.com oder powerplatform.com; URLs von Office-365-Connectors sind abgeschafft); pagerduty, der 32-stellige Events-API-v2-Routing-Schlüssel; telegram, das Bot-Token.

    Eine andere Form ergibt notification_destination_rejected. Es wird versiegelt, nie zurückgegeben und erscheint beim Lesen nur als destination_hint.

  • NotificationEventTypes — erforderlich: none

    Nur Webhook. Projektereignisse, die zusätzlich per POST gesendet werden, sobald sie auftreten, genau so, wie ein Webhook sie sendet: exakte Typen wie screen.online oder Präfixe, die auf .* enden, wie screen.*. notification.test wird nie verteilt.

  • NotificationList — erforderlich: items
  • NotificationPatch — erforderlich: none
  • NotificationProjectIDs — erforderlich: none

    Live-Projekte der Organisation, jedes einmal genannt. Eine leere Liste deckt keines ab.

  • NotificationReachDrop — erforderlich: none

    Der kleinste Rückgang der Reichweite einer Kampagne, für den eine reach_dropped-Meldung gesendet wird: screens ist die geringste Zahl verlorener Bildschirme (Standard 1) und percent, falls gesetzt, der kleinste Anteil der Bildschirme, die die Kampagne bei ihrer Veröffentlichung erreicht hat; ein Rückgang muss beides erfüllen.

    Ein kleinerer Rückgang stellt keine Meldung in die Warteschlange, und eine Meldung in der Warteschlange, deren Rückgang bis zur Fälligkeit darunter gesunken ist, wird übersprungen (condition_cleared). Nur mit der Bedingung reach_dropped; bei einer Benachrichtigung ohne sie invalid_request.

  • NotificationRecipients — erforderlich: none

    Nur E-Mail. owner (wer das Projekt besitzt, wenn eine Meldung gesendet wird) oder die user_id einer Person, die Mitglied des Projekts ist; eine user_id, die kein Mitglied bezeichnet, ergibt invalid_request. Jeder erhält die E-Mail an die bestätigte Adresse. Wer das Projekt inzwischen verlassen hat oder keine bestätigte Adresse hat, wird übersprungen.

  • NotificationSeverity — erforderlich: none

    Der Schweregrad einer Meldung, der am wenigsten schwere zuerst. Eine geöffnete Meldung hat den Schweregrad ihrer Bedingung: error für screen_offline und warning für jede andere Bedingung, sofern der Schweregrad der Benachrichtigung nichts anderes sagt. Eine behobene Meldung und ein Test sind info.

  • NotificationSeverityOverrides — erforderlich: none

    Bedingung zu Schweregrad für diese Benachrichtigung, etwa {"not_playing": "error"}. Sie zählt für min_severity und ist der Schweregrad, den Teams und PagerDuty für die Bedingung zeigen. Eine nicht aufgeführte Bedingung behält ihren Standard. Bei einem Patch löscht ein leeres Objekt, wie null, jede Übersteuerung.

  • NotificationTelegramChat — erforderlich: none

    Nur für Telegram; dort erforderlich. Der Chat, in den gepostet wird: seine numerische ID (negativ für eine Gruppe oder einen Kanal) oder @channelname. Keine Zugangsdaten.

  • NotificationUnsubscription — erforderlich: user_id, at
  • NotificationWrite — erforderlich: channel

    email sendet an Empfänger, webhook sendet per POST signiert an url, und slack, teams, pagerduty und telegram posten eine Nachricht pro Ausfall und Bildschirm in einen Chat oder Pager mit dem nur schreibbaren destination (telegram braucht außerdem telegram_chat_id), danach eine Wiederherstellung; PagerDuty öffnet einen Vorfall und behebt ihn. Sie brauchen mindestens eine Bedingung und nehmen kein event_types an.

  • OAuthAuthorization — erforderlich: id, client_name, client_registered, redirect_host, access, capabilities, created_at, expires_at
  • OAuthAuthorizationRedirect — erforderlich: redirect_uri
  • OAuthError — erforderlich: error
  • OAuthTokenResponse — erforderlich: access_token, token_type, expires_in
  • OnboardingSiteCTA — erforderlich: label, path, href, at

    Der Registrierungs- oder Anmeldelink, auf den die Person auf der Website geklickt hat.

  • OnboardingSiteVisit — erforderlich: path, at
  • OnboardingStepName — erforderlich: none

    Ein Schritt der Einstiegsabläufe, in Anzeigereihenfolge. email_verified, email_gate_reached und die Konto-Meilensteine (agent_connected, screen_paired, playlist_with_content, activated) werden vom Server geschrieben oder verknüpft und sind keine Namen, die ein Client sendet.

  • OnboardingStepRequest — erforderlich: journey_id, step
  • OnboardingValue — erforderlich: none

    Was die Person bei einem Schritt eingegeben hat: die eingegebene Adresse (email_submitted, reset_requested), der Name (signup_name_entered), Ja oder Nein (signup_marketing_choice), die gewählten Optionen oder der Folgetext (question_answered, question_follow_up), eine bei einer Einladung eingegebene Adresse oder ein dort eingegebener Name. Niemals ein Passwort, Code oder Token. Leer gilt als nicht vorhanden.

  • Operation — erforderlich: id, kind, state, created_at, updated_at
  • OperationAccepted — erforderlich: id, release_id, operation_id
  • OrganizationAdminInvitation — erforderlich: id, kind, delivery, status, recipient_email, organization_id, created_at, expires_at
  • OrganizationAdminInvitationCreate — erforderlich: emails
  • OrganizationAdminInvitationCreated — erforderlich: invitations
  • OrganizationAdminInvitationList — erforderlich: items, next_cursor
  • OrganizationAdmins — erforderlich: admins, candidates, revision
  • OrganizationAdminsUpdate — erforderlich: admin_user_ids
  • OrganizationBillingUsage — erforderlich: org_id, period, pool, allowance, stored_bytes, screens, projects, next_cursor
  • OrganizationDomainChallenge — erforderlich: organization_id, challenge_id, domain, name, value, expires_at
  • OrganizationDomainInput — erforderlich: domain
  • OrganizationDomainProof — erforderlich: challenge_id
  • OrganizationDomainRemoved — erforderlich: status
  • OrganizationGuestPolicy — erforderlich: mode, domains

    Die geltende Gastrichtlinie der Organisation. Gäste sind Personen, deren Heimatorganisation eine andere ist oder die keine haben; eine Richtlinie entfernt nie jemanden, der bereits Mitglied ist.

  • OrganizationGuestPolicyDomain — erforderlich: none

    Ein DNS-Name in Kleinbuchstaben mit mindestens zwei Labels, wie er nach dem @ einer verifizierten E-Mail-Adresse steht (internationalisierte Namen in ihrer xn--Form).

  • OrganizationGuestPolicyMode — erforderlich: none

    allow lässt jeden Gast zu. domains lässt einen Gast zu, dessen verifizierte E-Mail-Adresse bei einer der aufgeführten Domains liegt (genaue Übereinstimmung). none lässt keinen Gast zu. Heimatmitglieder sind nie Gäste.

  • OrganizationGuestPolicyResult — erforderlich: mode, domains, outside_policy

    Die aktuell geltende Gastrichtlinie, mit der Anzahl der Personen, die sie außen vor lässt.

  • OrganizationGuestPolicyUpdate — erforderlich: mode
  • OrganizationLibraryUpdate — erforderlich: project_id
  • OrganizationList — erforderlich: organizations, new_organization_allowed
  • OrganizationMemberInvitation — erforderlich: id, kind, delivery, status, recipient_email, organization_id, created_at, expires_at
  • OrganizationMemberInvitationCreate — erforderlich: emails
  • OrganizationMemberInvitationCreated — erforderlich: invitations
  • OrganizationMemberInvitationList — erforderlich: items, next_cursor
  • OrganizationNotificationList — erforderlich: items
  • OrganizationNotificationPatch — erforderlich: none

    Ein NotificationPatch und project_ids.

  • OrganizationNotificationWrite — erforderlich: channel

    Ein NotificationWrite und die Projekte, die die Benachrichtigung abdeckt. Fehlt project_ids oder ist es null, deckt die Benachrichtigung jedes Projekt der Organisation ab, auch später hinzugefügte Projekte; eine Liste deckt genau diese Projekte ab, jedes ein Live-Projekt der Organisation.

  • OrganizationPayments — erforderlich: organization_id, available, local_simulation, purchases
  • OrganizationPeople — erforderlich: projects, people, truncated
  • OrganizationPeopleMembership — erforderlich: project_id, role, can_approve
  • OrganizationPeoplePerson — erforderlich: user_id, display_name, email, admin, member, managed, outside_guest_policy, projects
  • OrganizationPeopleProject — erforderlich: project_id, name
  • OrganizationPerson — erforderlich: user_id, display_name, email
  • OrganizationPersonal — erforderlich: none

    Die Organisation ist nur die Hülle ihres einen Projekts: genau ein aktives Projekt, keine verifizierte Domain, kein Organisationsplan jetzt oder geplant und kein Admin außer dem Eigentümer dieses Projekts. Das Dashboard blendet die Organisationsebene dafür aus.

  • OrganizationProject — erforderlich: id, name, organization_id, status, screen_count
  • OrganizationProjectAccess — erforderlich: project_id, joined
  • OrganizationProjectAccessChange — erforderlich: project_id, user_id, access
  • OrganizationProjectAccessRequest — erforderlich: changes
  • OrganizationProjectAccessResult — erforderlich: changes
  • OrganizationProjectOwner — erforderlich: project_id, owner_user_id
  • OrganizationProjectOwnerUpdate — erforderlich: user_id
  • OrganizationProjectPage — erforderlich: projects, next_cursor
  • OrganizationRename — erforderlich: name
  • OrganizationSummary — erforderlich: id, name, personal
  • OrganizationView — erforderlich: id, name, personal, revision, admin, home, project_count, plan_id, free, plan_required, education_eligible, education_eligibility_source
  • PageDataCondition — erforderlich: key

    Ein card-data-Prädikat, ausgewertet vor der zivilen Zeit. Fehlende oder abgelaufene Daten stimmen nie überein. Die Seite respektiert auch ihre gewöhnlichen Zeitgrenzen. Erfordert die Host-Fähigkeit page.conditions; ältere Hosts erhalten die deaktivierte Seite.

  • PageFailure — erforderlich: page_id, code, at

    Neuester akzeptierter playback.page_failed-Bericht für diesen Bildschirm. Abwesend, bis ein Player einen meldet. Nur lesbare Projekt-Gesundheitsmetadaten; ändert nicht die Bildschirmrevision oder Manifest-Autorität.

  • PageVisibility — erforderlich: enabled

    Optionale Seiten-Sichtbarkeitsplanung. Sie ist ein Geschwister von advance und gehört nie zu screenrig.canvas/v1; sie beschreibt die Wiedergabeorchestrierung, nicht die Geometrie. Der Server validiert und überträgt diese Regeln als Daten. Der Player bewertet sie anhand der im Manifeststamm veröffentlichten Bildschirmzeitzone.

    Eine Seite ist berechtigt, wenn enabled true ist, now innerhalb von [from, until) liegt und entweder windows fehlt oder mindestens ein Fenster passt. Jede Playlist muss mindestens eine Seite ohne Sichtbarkeitsfeld behalten, sodass immer berechtigte Inhalte existieren. Konformitätsvektoren für die Bewertungsregeln sind die screenrig.schedule/v1-Familie in packages/schedule-contract.

  • PageVisibilityWindow — erforderlich: days

    Ein wiederkehrendes ziviles Zeitfenster. Das Weglassen von Start und Ende wählt den ganzen Tag aus. Wenn Ende kleiner oder gleich Start ist, überschreitet das Fenster Mitternacht und der Starttag besitzt es, also läuft Fr 22:00 bis 02:00 in den Samstagmorgen.

  • PairScreen — erforderlich: code
  • PairingClaim — erforderlich: screen, public_url
  • PairingClaimedEvent — erforderlich: type, completion_nonce
  • PairingComplete — erforderlich: completion_nonce
  • PairingCompletion — erforderlich: screen, public_url
  • PairingSession — erforderlich: code, expires_at
  • PasskeyAdditionProof — erforderlich: authorization_ceremony_id, authorization_credential
  • PlaybackAggregate — erforderlich: screen_id, media_id, filename, day, play_count, last_page_id, last_manifest_revision, first_started_at, last_started_at
  • PlaybackAggregateCsv — erforderlich: none

    RFC 4180 CSV, CRLF-Datensätze, UTF-8, mit der Kopfzeile screen_id,media_id,filename,primitive,day,play_count,last_page_id,last_manifest_revision,first_started_at,last_started_at. Zeiten sind RFC 3339 UTC. Eine Zelle, die mit =, +, -, @, Tabulator oder Wagenrücklauf beginnt, wird mit einem einfachen Anführungszeichen versehen, damit Tabellenkalkulationen sie nicht auswerten.

    Content-Disposition benennt playback-aggregates.csv. Ein Stream, der nach dem Header fehlschlägt, wird an der Verbindung abgebrochen.

  • PlaybackAggregateList — erforderlich: items
  • PlaybackApplicationStartedContext — erforderlich: manifest_revision, page_id, primitive_id, release_id
  • PlaybackApplicationStartedReport — erforderlich: severity, code, context

    Ein sichtbarer Start eines Anwendungsprimitivs auf einer Seite: Die Anwendung wurde auf dem Bildschirm sichtbar, vom Player-Controller einmal pro Seitenanzeige gemeldet – der Anwendungsinhalt meldet seine eigene Sichtbarkeit nie, und ein Paket-Download ist niemals ein Start.

    Der sendende Bildschirm ist authentifiziert; Seiten-, Primitive-, Release- und Manifest-Identitäten sind gemeldete Beobachtungen ohne Inhalts- oder Berechtigungsprüfungen. Speichert einen dauerhaften Abspiel-Datensatz pro Abspielvorgang (GET /api/playback/plays). Projektbesitzende Release-/Anwendungs-Haushaltszeitstempel folgen durch eine wiederherstellbare Batch-Projektion.

    Gewöhnliche Wiedergabe-Bestätigungen lassen optionale Kredit-Saldo-Header weg. Es gibt keine tägliche Aggregatzeile für Anwendungsstarts; die Wiedergabeaufzeichnungen sind der Nachweis.

  • PlaybackCompleteness — erforderlich: day_from, day_to, measured_plays, missing_plays, completeness, days, gaps, truncated

    Wie viele der von den Bildschirmen gemachten Wiedergaben das Backend erreicht haben, für die UTC-Tage day_from bis day_to (jeweils einschließlich). measured_plays und missing_plays sind die Summen von days, und completeness ist measured_plays geteilt durch ihre Summe, null, wenn beide 0 sind. days listet, älteste zuerst, nur die Tage mit einer gemessenen oder einer fehlenden Wiedergabe. gaps listet die Lücken in der Nummerierung der Wiedergaben, neueste zuerst.

    Wiedergaben ohne Nummer (ältere Player, Starts, die vor den Wiedergabenummern gespeichert wurden) sind in keiner dieser Zahlen enthalten.

  • PlaybackCompletenessDay — erforderlich: day, measured_plays, missing_plays, completeness

    Die Wiedergabenummerierung eines UTC-Empfangstags.

  • PlaybackCompletenessShare — erforderlich: none

    Angekommene Wiedergaben geteilt durch angekommene plus fehlende Wiedergaben, von 0 bis 1. null, wenn es keine von beiden gibt, wie bei älteren Playern, die keine Wiedergaben nummerieren.

  • PlaybackGap — erforderlich: screen_id, day, from, to, missing_plays

    Ein Block von Wiedergabenummern, die ein Player ausgelassen hat, sodass so viele Wiedergaben stattfanden und nie ankamen.

  • PlaybackGrant — erforderlich: none

    Der Wiedergabe-Handshake, den das Backend gewährt hat: die Schnittmenge aus dem PlaybackHandshake der Mint und dem, was dieses Backend unterstützt, angemeldet in der Sitzung. Wird aus der Sitzung ausgelassen, wenn nichts sich überschneidet, sodass eine Sitzung ohne Handshake unverändert bleibt. Ein Player verwendet /screen/manifest nur, wenn manifest_versions 3 enthält.

  • PlaybackHandshake — erforderlich: none

    Optionales Wiedergabe-Handshake, das ein Player bei mint erklärt. Es ist ein Hinweis, der Verhalten auswählt, niemals Autorisierung: unbekannte Mitglieder und Einträge falschen Typs werden ignoriert, und ein Wert, der kein Objekt ist, verhandelt nichts. Die mint-Antwort spiegelt die unterstützte Schnittmenge als PlaybackGrant wider. adslot-v1 wird nur an gepaarte Sitzungen vergeben.

  • PlaybackMediaStartedContext — erforderlich: media_id, manifest_revision, page_id, primitive
  • PlaybackMediaStartedReport — erforderlich: severity, code, context

    Ein sichtbarer Start eines Bild- oder Video-Primitivs auf einer Seite. Player senden dies einmal pro Seitenanzeige des Mediums, für Bilder genau wie für Videos; Schleifen innerhalb einer Anzeige sind keine Neustarts. Der sendende Bildschirm ist authentifiziert; Medien-, Seiten-, Primitiv- und Manifest-Identitäten sind Beobachtungen ohne Inhalts- oder Berechtigungsprüfungen.

    Erfolg bestätigt dauerhafte rohe Einfügung; tägliche Zählungen erfolgen über eine wiederherstellbare gebündelte Projektion. Übliche Wiedergabe-Bestätigungen lassen optionale Guthaben-Header weg.

  • PlaybackPageFailedContext — erforderlich: page_id, code
  • PlaybackPageFailedReport — erforderlich: severity, code, context

    Meldet, dass eine Seite nicht bereitgestellt werden konnte. Bei Annahme ersetzt der Server Screen.last_page_failure und fügt im selben Vorgang ein dauerhaftes, projektgebundenes playback.page_failed-Ereignis hinzu. Die Bildschirmrevision oder Manifestautorität wird nicht geändert.

  • PlaybackPlay — erforderlich: screen_id, page_id, media_id, primitive, received_at

    Ein dauerhafter vom Player gemeldeter Start eines Bildes, Videos oder einer Anwendung.

    Die Sitzung authentifiziert Bildschirm und Projekt; Element-, Seiten-, Manifest-, Primitive- und Release-Identitäten sind gemeldete Beobachtungen und autorisieren keinen Inhaltszugriff. playlist_id und playlist_revision sind optionale Metadaten, die asynchron aus einem passenden Bildschirmmanifest angereichert werden; fehlende Metadaten bleiben abwesend.

    Anwendungsstarts tragen release_id mit leerer media_id und primitive. primitive_id und started_at sind nur vorhanden, wenn der Player sie meldet; started_at wird auf [received_at - 24h, received_at + 5m] begrenzt.

    Eine JSON-Seite nennt außerdem Bildschirm, Medium, Playlist und Anwendung als Anzeigetext, der beim Ausliefern gelesen wird; der CSV-Export sowie die xlsx- und pdf-Berichte lassen diese Namen weg.

  • PlaybackPlayCsv — erforderlich: none

    RFC 4180 CSV, CRLF-Datensätze, UTF-8, mit der Kopfzeile screen_id,playlist_id,page_id,primitive_id,media_id,primitive,started_at,received_at,manifest_revision,playlist_revision in dieser festen Reihenfolge; ein fehlender Wert ist eine leere Zelle. Zeiten sind RFC 3339 UTC. Eine Zelle, die mit =, +, -, @, Tabulator oder Wagenrücklauf beginnt, wird mit einem einfachen Anführungszeichen versehen.

    Content-Disposition benennt playback-plays.csv. Ein kompletter Export endet nach seinem letzten CRLF-Datensatz ohne Trailer; ein Stream, der nach dem Header fehlschlägt, wird an der Verbindung abgebrochen (der Client sieht einen Transportfehler, nie ein sauberes Ende), daher Wiederholung ab dem letzten received_at.

  • PlaybackPlayList — erforderlich: items, next_cursor
  • PlaybackTotals — erforderlich: by, day_from, day_to, truncated

    Wiedergabesummen über die inklusiven UTC-Tage day_from bis day_to. Genau eines von days (by=day), screens (by=screen), media (by=media) oder screen_days (by=screen_day, gruppiert nach Bildschirm in Rangfolge, Tage aufsteigend) ist vorhanden, das von der Anfrage benannte. truncated ist true, wenn ein Ranking Schlüssel weglassen kann, die unter dem Besten eines Abschnitts oder eines Stores rangieren.

  • PlaybackTotalsDay — erforderlich: day, play_count, first_started_at, last_started_at
  • PlaybackTotalsMedia — erforderlich: media_id, play_count, first_started_at, last_started_at
  • PlaybackTotalsScreen — erforderlich: screen_id, play_count, first_started_at, last_started_at
  • PlaybackTotalsScreenDay — erforderlich: screen_id, day, play_count
  • PlaybackVideoStartedContext — erforderlich: media_id, manifest_revision, page_id
  • PlaybackVideoStartedReport — erforderlich: severity, code, context

    Einen sichtbaren Video-Start melden. Dies verwendet dieselbe tägliche Aggregation wie playback.media_started mit primitiven Videos. Pro Start eine Meldung senden; das Senden beider Ereignistypen zählt den Start doppelt. Verwenden Sie playback.media_started, wenn Sie sowohl Bilder als auch Videos melden.

  • PlayerBrowserIdentity — erforderlich: kind, version, pwa

    Browser-Engine und Installationsmodus für Browser-Player, einschließlich nativer Shells. Ein fehlerhafter optionaler Browser-Hinweis wird verworfen, ohne den Mint abzulehnen.

  • PlayerCardsIdentity — erforderlich: none

    Die eingebaute Kartenbibliothek, die der Player mitführt (docs/player-compatibility.md §3.1): die Bibliothek CalVer und die Semver jeder Karte, deren Major angibt, welche Kartenplatzierungen der Bildschirm rendert. Auf dem Bildschirm mit dem Rest des Players gespeichert. Fehlerhafte Einträge werden einzeln verworfen; es ist niemals ein 400.

  • PlayerIdentity — erforderlich: kind

    Die Selbstidentifikation des Players wird nur auf den drei Mint-Routen gesendet (docs/player-compatibility.md §3.1). Sie ist ein Hinweis und niemals eine Autorisierung und wird nicht durch den nativen Nachweis abgedeckt. Sie wird tolerant gelesen: Unbekannte Mitglieder werden ignoriert, ein ungültiges optionales Mitglied wird eigenständig verworfen, und ein Player, der kein Objekt ist oder keine gültige Art hat, erklärt nichts.

    Sie ist niemals ein 400. Ein gekoppelter Mint speichert sie auf dem Bildschirm für das Operator-Flotten-Histogramm.

  • PlayerPublicKey — erforderlich: kty, crv, x
  • PlayerShellIdentity — erforderlich: kind

    Die Shell, unter der ein Web-Player läuft. Deren Kompatibilitätstoken werden aufgezeichnet, nie gewährt. Ein ungültiger Typ verwirft die Shell.

  • Playlist — erforderlich: id, name, revision, pages
  • PlaylistAdvance — erforderlich: none
  • PlaylistAdvanceWrite — erforderlich: none
  • PlaylistApplicationAdvance — erforderlich: mode, max_ms
  • PlaylistApplicationPrimitive — erforderlich: id, primitive, release_id, rect, layer, content_fit
  • PlaylistApplicationPrimitiveWrite — erforderlich: id, primitive, release_id, layer, content_fit
  • PlaylistApproval — erforderlich: state, review_id

    Vorhanden, während eine Überprüfung dieser Playlist aussteht. Die Playlist selbst ist die Live-(genehmigte) Version.

  • PlaylistAudio — erforderlich: tracks, loop, volume

    Gespeicherter Playlist-Soundtrack mit ausgefüllten Standardwerten.

  • PlaylistAudioCue — erforderlich: track

    Optionaler Soundtrack-Hinweis auf einer gewöhnlichen Seite. Wenn die Seite aktuell wird, wechselt der Player zum benannten Titel von dessen Anfang, sofern er nicht bereits spielt; restart true startet ihn auch dann neu. Die Sequenz wird von diesem Titel fortgesetzt.

    Player können einen Hinweis ignorieren. track muss eine Track-ID in der Playlist-Audio benennen; ein Cue ohne Playlist-Audio ist invalid_request. Nicht erlaubt auf Adslot-Seiten. Eine Seite mit Advance-Modus audio_end endet, wenn der angesagte Track endet; sie benötigt diesen Cue.

  • PlaylistAudioEndAdvance — erforderlich: mode, max_ms
  • PlaylistAudioEndAdvanceWrite — erforderlich: mode

    Die Seite endet, wenn die Tonspur endet, die ihr audio_cue benennt. Die Seite muss einen audio_cue tragen und die Playlist eine Audio-Tonspur (docs/playlist-audio.md).

  • PlaylistAudioTrack — erforderlich: id, media_id
  • PlaylistAudioWrite — erforderlich: tracks

    Optionale Playlist-Soundtrack: geordnete, bereite Audio-(MP3)-Medien, die kontinuierlich abgespielt werden, während sich Seiten ändern (docs/playlist-audio.md). Seitenwechsel stoppen oder starten ihn nie neu. PUT ersetzt die gesamte Playlist, das Weglassen von Audio entfernt den Soundtrack.

  • PlaylistCanvas — erforderlich: width, height, background
  • PlaylistCardPrimitive — erforderlich: id, primitive, card, major, params, rect, layer, content_fit, controller
  • PlaylistCardPrimitiveWrite — erforderlich: id, primitive, card, layout, content_fit

    Eine eingebaute Karte, die der Player nativ zeichnet (Uhr, Wetter, Menütafel, Ticker, KPI-Kacheln und der Rest des katalogisierten Kartenangebots, screenrig.cards.contract/v1). Das Layout platziert sie: voll (die ganze Leinwand), frei (eigenes Rechteck und Ebene), zentriert (900 x 420), breit (die Leinwand 30 vom linken und rechten Rand und 80 vom oberen und unteren Rand eingerückt), Kopfzeile (die ganze obere Kante, 80 hoch), Fußzeile (die ganze untere Kante, 80 hoch), Ecke (270 Quadrat), Chip (240 x 70) oder Streifen (die ganze Kante, 120 hoch), in 1080p-Design-Einheiten, skaliert mit min(Leinwandbreite, Leinwandhöhe) / 1080. Ecke und Chip nehmen eine Ankerecke (oben links, oben rechts, unten links, unten rechts) und Streifen eine Ankerkante (oben, unten, links, rechts); die anderen Layouts nehmen keine.

    Außer bei free leitet der Server rect und layer vom Canvas oder von den Frame-Displays cover ab: lassen Sie sie weg oder senden Sie genau das, was er ableitet.

    Eine Seite enthält höchstens eine volle, mittige oder breite Karte, eine Eck- oder Chip-Karte pro Ecke und einen Streifen pro Kante (eine Karte mit Präsenz kann eine Kante mit einem normalen Streifen teilen); ein Header nimmt den normalen Streifenplatz der oberen Kante ein und ein Footer den der unteren, sodass eine Seite höchstens je einen davon enthält, keinen normalen Streifen an dieser Kante, und eine Karte mit Präsenz kann ihn dennoch teilen.

    Eine Ecke oder ein Absplitterung an einer Kante, die einen Streifen hält, bewegt sich um 120 vorbei, und an einem Kopf- oder Fußbereich um 80.

    Bei einer Playlist mit Format ist displays der Rahmen, aus dem das Layout abgeleitet wird (full ist der Rahmen, corner die Ecke des Rahmens; free verweigert displays), die Karten-Skalierung ist die Kachel min(Breite, Höhe) / 1080 = 1 statt vom Rahmen abgeleitet, und zwei Karten konkurrieren um einen Slot oder verschieben sich über die Streifen der anderen, nur wenn ihre Rahmen ein Display teilen (kein displays ist jedes Display).

    Die Stufe einer Karte bestimmt ihre Layouts (GET /api/card-types): core erlaubt alle neun, fullscreen erlaubt full. params enthält die statischen Eigenschaften der Platzierung (Theme, Standort, Titel, Spaltendefinitionen) und ändert sich nur durch eine erneute Veröffentlichung.

    Ein String in params kann {screen.name}, {screen.timezone} und {screen.field.NAME} enthalten, und ein Parameter location darf der String {screen.location} sein; das Backend setzt sie für jeden Bildschirm ein, sodass eine Playlist jedem Bildschirm seine eigenen Werte zeigt. data benennt ein Karten-Datendokument (GET/PUT /api/card-data/{key}), das die dynamischen Eigenschaften der Karte enthält (Menüabschnitte, Tickereinträge, KPI-Kacheln); Agents ändern es ohne erneute Veröffentlichung. {screen.field.NAME} in einem data-Schlüssel liest ein Dokument pro Bildschirm, zum Beispiel menu-{screen.field.store_number}.

    Mit Daten dürfen params keine dynamischen Eigenschaften enthalten; ohne Daten enthalten params die gesamte Konfiguration. Jeder String in params, der mit media: beginnt, ist eine Medienreferenz, media:<id>, die ein fertiges Bild in diesem Projekt benennt, das die Karte zeichnet (Spotlight people[].photo, Produktgitter products[].photo); eine Karte verwendet niemals eine Bild-URL.

    Veröffentlichen lehnt eine unbekannte Karte oder ungültige Haupt- und Parameter (card_invalid), ein Layout, Anker, Rechteck oder Ebene, die die Karte nicht tragen darf (card_layout_invalid), Karten, die denselben Platz auf der Seite beanspruchen (card_layout_conflict), eine Medienreferenz, die kein fertiges Bild des Projekts benennt (card_media_invalid), und einen gebundenen Schlüssel, dessen gespeichertes Dokument die Karte ablehnt (card_data_invalid), ab.

    Die Bildschirme, die die Platzierung anzeigen, erhalten deren Medien, und ein Live-Schreiben genehmigt ausstehende Medien, die es benennt, wie bei einem by:id-Selektor. Eine Karte mit einem Drittanbieter-Feed (Wetter) liest diesen aus dem Schlüssel, den der Server aus seinen statischen Parametern ableitet.

  • PlaylistCreateRequest — erforderlich: none

    Die Seiten einer Playlist, eine Vorlage, aus der sie erstellt wird, oder die integrierte Starter-Vorlage.

  • PlaylistDisplays — erforderlich: none

    Nur Playlists mit einem Format. Die Displays, die eine Primitive abdeckt: aufsteigende, eindeutige 1-basierte Displaynummern innerhalb von 1..format.displays, die ein Rechteck der Kacheln der Wand füllen, wie [2], [1, 2] oder, bei einem Raster mit 4 Spalten, [2, 3, 6, 7]. In einer Reihe oder einer Spalte sind sie zusammenhängend.

    Der Server leitet rect als Begrenzungsrahmen dieser Kacheln ab; rect wird weggelassen oder ist genau der abgeleitete Wert. Gespeichert und beim Lesen zurückgegeben.

  • PlaylistDurationAdvance — erforderlich: mode, after_ms
  • PlaylistExpandRequest — erforderlich: none
  • PlaylistExpanded — erforderlich: pages
  • PlaylistFormat — erforderlich: none

    Wofür eine Playlist erstellt ist: eine Videowand (PlaylistWallFormat) oder eine Region (PlaylistRegionFormat), nie beides. Eine Playlist ohne Format ist eine gewöhnliche Playlist, die als Seite an jeden Bildschirm gebunden wird.

  • PlaylistFromTemplate — erforderlich: playlist_id

    Erstellt eine Playlist aus einer Vorlage: ihre aktuellen Seiten mit den eingetragenen Werten, geprüft nach allen Playlist-Regeln. Ein Medienwert muss ein bereites Medium der richtigen Art sein, ein URL-Wert eine http- oder https-Adresse.

  • PlaylistFromTemplateWrite — erforderlich: name, from_template

    Erstellt eine Playlist aus einer Vorlage. Senden Sie nur name und from_template.

  • PlaylistIframePrimitive — erforderlich: id, primitive, src, title, rect, layer, content_fit, controller
  • PlaylistIframePrimitiveWrite — erforderlich: id, primitive, src, title, layer, content_fit
  • PlaylistImagePrimitive — erforderlich: id, primitive, selector, resolved_media, rect, layer, content_fit, controller
  • PlaylistImagePrimitiveWrite — erforderlich: id, primitive, selector, layer, content_fit
  • PlaylistInstance — erforderlich: id, name, revision, template_revision, outdated
  • PlaylistInstanceList — erforderlich: items
  • PlaylistIntrinsicSize — erforderlich: width, height
  • PlaylistList — erforderlich: items
  • PlaylistMediaEndAdvance — erforderlich: mode, max_ms
  • PlaylistMediaEndAdvanceWrite — erforderlich: mode
  • PlaylistMediaSelector — erforderlich: none
  • PlaylistMediaSelectorByAll — erforderlich: by
  • PlaylistMediaSelectorByFolder — erforderlich: by, folder_id

    Die fertigen Dateien des primitiven Ordners direkt in einem Medienordner (GET /api/media-folders), nicht die seiner Unterordner, geordnet und getaktet wie bei :all. Wie ein Tag wird der Ordner bei jeder Selektorenauflösung erneut gelesen, sodass das Verschieben von Dateien hinein oder heraus ändert, was die abspielenden Bildschirme in ihrer nächsten Schleife anzeigen.

    Das Schreiben einer Playlist erfordert, dass der Ordner im Projekt existiert; er darf leer sein. Ein Ordner, der keine fertige Datei des Primitives enthält oder später gelöscht wird, entspricht nichts. Player erhalten ihn als by:all; der Server löst den Ordner auf.

  • PlaylistMediaSelectorByID — erforderlich: by, media_id
  • PlaylistMediaSelectorByIDs — erforderlich: by, media_ids
  • PlaylistMediaSelectorByTag — erforderlich: by
  • PlaylistPage — erforderlich: id, canvas, transition, advance, primitives
  • PlaylistPageAdd — erforderlich: page
  • PlaylistPageStructure — erforderlich: id

    Eine Seite, die bleibt, und die zwei Seiteneinstellungen, die eine Person ändert. advance ersetzt das Seiten-Advance, wenn vorhanden, und behält es bei, wenn ausgelassen; eine Anzeigen-Slot-Seite hat keines. visibility ersetzt die Sichtbarkeit der Seite, wenn ein Objekt, entfernt sie, wenn null, und behält sie bei, wenn ausgelassen.

    Ein Sichtbarkeitsobjekt, das nur enabled true setzt, ist eine No-Op und wird abgelehnt: Senden Sie null, um die Regeln zu entfernen.

  • PlaylistPageV2 — erforderlich: none
  • PlaylistPageWrite — erforderlich: id, canvas, transition, advance, primitives
  • PlaylistPageWriteV2 — erforderlich: none
  • PlaylistPatch — erforderlich: none

    Weil ausgelassene Felder erhalten bleiben. Angegebener Name, Seiten, Audio und Format ersetzen diese Top-Level-Werte; Audio oder Format null entfernt es. Angegebene Seiten werden gegen das gespeicherte Format geprüft, wenn Format ausgelassen wird, und ein angegebenes Format gegen die gespeicherten Seiten, wenn Seiten ausgelassen werden. Identität, Revision, Kommentare und Zeitstempel können hier nicht gesetzt werden.

    Kommentare haben eigene Endpunkte.

  • PlaylistPrimitive — erforderlich: none
  • PlaylistPrimitiveLocked — erforderlich: none

    Ein gesperrtes Primitiv ist festgelegter Markeninhalt einer Vorlage (Logo, Hintergrund, Layout, Design): Nur die Projektinhaberin oder der Projektinhaber oder ein Mitglied, das genehmigen darf, fügt es hinzu, entfernt, verschiebt oder bearbeitet es oder hebt die Sperre auf, und eine aus der Vorlage erstellte Playlist behält die Sperre. Ohne Angabe ist es nicht gesperrt. Ein gesperrtes Primitiv kann kein Feld lesen.

    Eine Änderung durch jede andere Person ist primitive_locked (403) oder, unter Propose, eine Prüfung.

  • PlaylistPrimitiveWrite — erforderlich: none
  • PlaylistRect — erforderlich: x, y, width, height
  • PlaylistRegionFormat — erforderlich: region, orientation

    Ein Streifen, der entlang einer Kante eines Displays über die Seite gezeichnet wird: ein header am oberen Rand, ein footer am unteren Rand, ein side am rechten Rand in voller Höhe. orientation ist die Ausrichtung des Displays, für das er gemacht ist, wie der Betrachter sie nach der Drehung sieht.

    Jede Seite hat dieselbe Leinwand (width und height); ein header oder footer ist breiter als hoch und ein side höher als breit, wobei die lange Seite mindestens doppelt so lang wie die kurze ist, sonst 400 invalid_request bei pages[i].canvas.

    Die Playlist enthält nur Bild- und Karten-Primitive (eine Seite mit Video, Stream, iframe, Anwendung oder Werbeslot wird abgelehnt) und hat keinen Soundtrack (Audio wird abgelehnt); ein Primitiv nennt keine Displays.

    Eine Regions-Playlist ist nie ein Bildschirm-Standard, ein Ordner-Standard oder eine Übernahme: Sie läuft als Zeitplaneintrag oder als Kampagne mit covers auf ihre Region (covers main und die ganze Seite lehnen sie ab), und covers header, footer oder side braucht eine Regions-Playlist dieser Region.

    Der Eintrag oder die Kampagne wird mit 409 playlist_format_mismatch abgelehnt, wenn der Streifen auf keinem der anvisierten Displays angeordnet ist: Ein Streifen wird auf einem Display seiner Ausrichtung angeordnet, beurteilt auf der Fläche, die der Player nach der Drehung meldet (die Wanddrehung des Bildschirms, wenn er keine gemeldet hat), und nur solange er höchstens die Hälfte des Displays abdecken würde (seine Höhe bei einem header oder footer, seine Breite bei einem side).

    Eine Kampagne wird nur abgelehnt, wenn sie auf keinem Bildschirm ihrer Zielgruppe angeordnet ist; auf einem Bildschirm einer gemischten Zielgruppe, auf dem sie es nicht ist, verlässt die Kampagne den Stack dieses Bildschirms, und ihre Erklärung lautet region_not_laid_out.

    Eine Formatänderung, die eine Playlist in eine Region hinein, aus einer Region heraus oder in eine andere Region verschiebt, wird mit 409 resource_conflict abgelehnt, solange ein Bildschirm-Zeitplan, eine Übernahme oder ein Standard, ein Ordner-Standard oder eine Kampagne sie verwendet.

  • PlaylistResolvedMedia — erforderlich: media_id, intrinsic_size
  • PlaylistRevision — erforderlich: revision, created_at, change, name, page_count, current

    One stored revision of a playlist. change says what made it: created (the first revision), edited (a replace, patch, structure change or applied review), promoted (a copy of an earlier revision, named by restored_from), or baseline (the revision the playlist held when its history began, before any write recorded one).

    Ein Wert, den dieser Leser nicht kennt, gilt als edited.

  • PlaylistRevisionAuthor — erforderlich: type, name

    Wer die Revision erstellt hat, wie das Ereignisprotokoll des Projekts sie nennt; fehlt, wenn der Schreibvorgang niemanden nannte (eine Baseline oder Systemarbeit).

  • PlaylistRevisionDetail — erforderlich: revision, playlist
  • PlaylistRevisionList — erforderlich: items
  • PlaylistStarterWrite — erforderlich: starter

    Fügt die integrierte Vorlage „Dringende Mitteilung“ hinzu (eine Überschrift und eine Nachricht). Senden Sie nur starter und optional name.

  • PlaylistStinger — erforderlich: none

    Eine nur für Übergänge bestimmte Stinger-Karte (Major 1). Alle Mitglieder sind optional; Standardwerte bleiben in der synthetischen Laufzeitplatzierung. hang_ms standardmäßig 1000 und höchstens 60 % der Übergangs-duration_ms (vom Server geprüft). logo benennt ein bereites Bild in diesem Projekt, das den Medienzugriffspfad der Karte verwendet.

  • PlaylistStreamPrimitive — erforderlich: id, primitive, sources, fallback_media_id, rect, layer, content_fit, muted, controller, resolved_media
  • PlaylistStreamPrimitiveWrite — erforderlich: id, primitive, sources, fallback_media_id, layer, content_fit
  • PlaylistStructurePatch — erforderlich: none

    Die Struktur einer Playlist und nichts, was eine Seite anzeigt (patchPlaylistStructure). Ausgelassene Mitglieder bleiben erhalten. Ein übergebener Name ersetzt den Namen. Übergebene Seiten sind die vollständige neue Reihenfolge der Seiten, die die Playlist enthält: eine gespeicherte Seite, die ausgelassen wird, wird entfernt.

    Seiteninhalt (Leinwand, Übergang, audio_cue, Primitive, Kommentare) und der Soundtrack können nicht gesendet werden und sind immer die gespeicherten.

  • PlaylistTemplateField — erforderlich: name, label, type

    Ein Wert, den eine Vorlage annimmt. Seiten lesen ihn als {field.NAME}: in den params einer Karte (Text- und URL-Felder), als media_id des Selektors eines Bildes oder Videos (Medienfeld) oder als gesamtes src eines Iframes (URL-Feld).

  • PlaylistTemplateFields — erforderlich: none

    Das Deklarieren von Feldern macht die Playlist zu einer Vorlage. Jeder von einer Seite gelesene Platzhalter muss ein deklariertes Feld des richtigen Typs nennen, und jedes Feld muss gelesen werden; eine Playlist ohne Felder liest keine Platzhalter. Eine Vorlage wird nie auf einem Bildschirm gezeigt (playlist_is_template). PUT ohne fields behält sie; null oder ein leeres Array entfernt sie.

  • PlaylistTransition — erforderlich: type, duration_ms

    Seitenübergang. Typ und duration_ms sind beide erforderlich; OpenAPI setzt sie nicht standardmäßig. Beispiele für Swipe-Autorenschaft verwenden duration_ms 600; dieser Wert ist kein Schema-Standard.

  • PlaylistV2 — erforderlich: id, name, revision, pages
  • PlaylistV2List — erforderlich: items
  • PlaylistValuesChange — erforderlich: values
  • PlaylistVideoPrimitive — erforderlich: id, primitive, selector, resolved_media, muted, loop, rect, layer, content_fit, controller
  • PlaylistVideoPrimitiveWrite — erforderlich: id, primitive, selector, layer, content_fit
  • PlaylistWallFormat — erforderlich: displays, arrangement, orientation

    Die Videowand, für die eine Playlist erstellt wird: 2 bis 12 Displays, Kacheln von jeweils 1920 x 1080 (Querformat) oder 1080 x 1920 (Hochformat), angeordnet in einer Reihe, einer Spalte oder einem Raster. Eine Reihe hat die Displays als Spalten und eine Zeile; eine Spalte hat eine Spalte und die Displays als Zeilen; ein Raster hat Spalten und Displays / Spalten Zeilen.

    Display n sitzt in Spalte (n - 1) mod columns und Zeile floor((n - 1) / columns): von links nach rechts, dann von oben nach unten.

    Die Leinwand aus c Spalten und r Zeilen von Kacheln mit Breite w und Höhe h ist (c * w, r * h), z. B. 5760 x 1080 für 3 Querformat-Displays in einer Reihe, 1080 x 3840 für 2 Hochformat-Displays in einer Spalte und 7680 x 3240 für 12 Querformat-Displays in einem Raster mit 4 Spalten.

    Die Breite und Höhe der Leinwand jeder normalen Seite muss genau übereinstimmen, sonst 400 invalid_request bei pages[i].canvas. Die Kartenskala auf einer solchen Playlist ist das Minimum aus Breite und Höhe der Kachel geteilt durch 1080 = 1.

    Eine Playlist mit Format darf nur an einen Bildschirm gebunden werden, dessen Wand dieselbe Form hat (Displays = Anzahl der Ausgänge, Anordnung, Spalten, Hochformat genau dann, wenn die Drehung 90 oder 270 ist), sonst 409 playlist_format_mismatch: Zuweisung, Flottenzuweisung, Zeitplaneinträge und Übernahme. Eine Playlist ohne Format bindet an jeden Bildschirm.

  • PlaylistWarning — erforderlich: code, message, page_id, primitive_id

    Etwas, worauf der Autor eines erfolgreichen Schreibvorgangs reagieren sollte. Der Schreibvorgang hat gespeichert, was er trug; eine Warnung lässt ihn nie scheitern. Ein Playlist-Schreibvorgang antwortet mit Warnungen auf der Playlist; ein Bildschirm-Schreibvorgang (updateScreen, die Felder-, Standort- und Playlist-Routen des Dashboards) auf dem Bildschirm; eine Flottenzuweisung auf der Ergebnisseite.

    Zwei Codes. iframe_framing_refused: Eine öffentliche https-Seite, die ein Iframe-Primitiv nennt (sein src oder sein fallback_src), sendet X-Frame-Options (DENY, SAMEORIGIN oder das veraltete ALLOW-FROM) oder eine Content-Security-Policy-frame-ancestors-Liste, die den Ursprung der Player-Web-App nicht zulässt.

    Die Player-Web-App und die Player für macOS, Samsung Tizen, LG webOS und BrightSign betten die Seite ein und können sie daher nicht anzeigen; Android-, Linux- und Windows-Player öffnen eine iframe-Seite als ganze Seite und sind nicht betroffen.

    Das Backend liest nach dem erfolgreichen Schreibvorgang die Antwort-Header von höchstens 8 verschiedenen Seiten pro Vorgang; eine nicht rechtzeitig erreichbare oder fehlerhaft antwortende Seite wird nicht gemeldet. Jede Seite erscheint einmal mit dem ersten verwendenden Element und fügt dem Projektprotokoll ein Ereignis playlist.iframe_framing_refused (Warnung) hinzu.

    Ein src mit Bildschirm-Token ist keine einzelne Seite und wird nicht gelesen. screen_fact_missing: Einem Bildschirm, den der Schreibvorgang erreicht, fehlt ein Wert, den das src eines Iframes oder die Parameter einer Anwendung über ein Bildschirm-Token lesen ({screen.field.NAME}, {screen.location.…}, {screen.timezone}), oder seine vorhandenen Werte füllen sich zu etwas, das das Manifest ablehnt (eine Adresse über 2048 Zeichen, ein Pfadsegment . oder .., Startparameter über 4096 Zeichen in der Start-URL), sodass das Primitiv aus dem Manifest dieses Bildschirms weggelassen wird (Manifest-Diagnose screen_fact_missing oder screen_fact_invalid), bis der Bildschirm den Wert hat.

    Eine Warnung pro Schreibvorgang nennt das erste solche Primitiv, die Token, die kein aufgelisteter Bildschirm füllen konnte (höchstens 64), die ersten 20 betroffenen Bildschirme und deren Anzahl.

    Ein Schreibvorgang auf eine Playlist (Ersetzen, Patch, Strukturänderung, Promote oder angewendete Prüfung) erreicht die Bildschirme, die die Playlist zeigen; ein Schreibvorgang auf einen Bildschirm erreicht diesen Bildschirm, und zwar für die Playlist, die er zeigt, und die, die ihm gerade zugewiesen wurde; eine Flottenzuweisung erreicht die Bildschirme ihrer Seite; die Genehmigung einer Bildschirmänderung erreicht die Bildschirme, die sie nennt.

  • PlaylistWrite — erforderlich: name, pages
  • PlaylistWriteV2 — erforderlich: name, pages
  • PrimitiveEnter — erforderlich: type

    Optionales Objekt enter. Playlist-Schreibvorgang und das Laufzeitmanifest verwenden dieses Objekt unverändert; es gibt keine Umbenennung in snake_case darin. Fehlt es, bedeutet das, dass die Darstellung in Ruhe mit voller Deckkraft erfolgt. Optionales ganzzahliges Stagger von 0 bis 8 verzögert den Start um stagger*120 ms nach der gemeinsamen 500 ms Verzögerung. Fehlt oder 0 ist der heutige Start. Die Dauer ist eine benannte Konstante in screenrig.canvas/v1.

  • PrimitiveMotion — erforderlich: none

    Optionaler persistenter Objektbewegung. Playlist-Schreibvorgang und das Laufzeitmanifest verwenden dieses Objekt unverändert; es gibt keine Umbenennung in snake_case darin. Fehlt es, bleibt das Primitive nach enter in Ruhe.

    Unverändert kopiert. Spin und Drift gelten nur für Bild und Video; Anwendung und iframe mit Spin oder Drift werden vom Server abgelehnt (motion_not_allowed_for_primitive). Pfad gilt für Bild, Video, Anwendung und iframe. Diese Einschränkung ist nicht als OpenAPI if/then kodiert.

  • PrimitiveMotionDrift — erforderlich: type, zoom, direction, speed

    Kontinuierliche langsame Skalierung um das Zentrum des clipRect kombiniert mit langsamer Verschiebung. Nur Bild und Video; der Server lehnt Drift bei Anwendung und iframe ab. Ping-Pong-Effekt; keine Sprünge.

  • PrimitiveMotionPath — erforderlich: type, points, rate

    Translation entlang einer Polylinie von Leinwandeinheiten-Wegpunkten nach dem erstellten Rechteck. loop ist standardmäßig loop, wenn ausgelassen. Gültig für Bild, Video, Anwendung und iframe.

  • PrimitiveMotionPoint — erforderlich: x, y
  • PrimitiveMotionSpin — erforderlich: type, direction, speed

    Kontinuierliche Rotation um das Zentrum des clipRect. Nur Bild und Video; der Server lehnt Spin bei Anwendung und iframe ab.

  • Problem — erforderlich: errors, instance, request_id

    Das Problemdokument, das jede Route außer den Player-gerichteten Laufzeit-, Inhalts- und Probe-Routen (RuntimeProblem) beantwortet. Der Fehler selbst ist errors[0]: sein Status, Code, Typ, Titel, Detail und Hinweis. Nur Dokumentmitglieder bleiben auf oberster Ebene. Verzweigung nach errors[0].code, niemals nach detail oder hint, die Prosa sind.

    Ein beanstandetes Anforderungsfeld fügt errors[0].field hinzu; jedes weitere beanstandete Feld ist ein eigener Eintrag mit den Details dieses Feldes.

  • ProblemError — erforderlich: status, code, type, title, detail, hint

    Ein Fehler eines Problemdokuments. Mitglieder darüber hinaus beschreiben diesen Fehler weiter (zum Beispiel Abhängigkeiten von not_ready).

  • ProblemField — erforderlich: field, code, detail
  • Project — erforderlich: id, revision, status, email, used_bytes, reserved_bytes, screen_count, content_limit_bytes, screen_limit, credit_remaining, created_at, updated_at, name
  • ProjectBillingUsage — erforderlich: period, usage, stored_bytes, allowance
  • ProjectCapabilities — erforderlich: project_id, plan_id, features, feature_revision, capabilities, media_video_bytes, plan_features, limits
  • ProjectContext — erforderlich: project, organization
  • ProjectContextList — erforderlich: projects
  • ProjectCreate — erforderlich: name
  • ProjectDeleteConfirmation — erforderlich: name, revision
  • ProjectDeletionPreview — erforderlich: project, organization, devices, allowed
  • ProjectFeatures — erforderlich: advertiser, screens
  • ProjectMove — erforderlich: organization_id
  • ProjectMoveDestinations — erforderlich: organizations
  • ProjectName — erforderlich: none

    Gekürzter druckbarer Projektname. Steuert Steuerzeichen, URL-ähnlichen Text, @, www. und :// ab.

  • ProjectOwnerTransfer — erforderlich: user_id
  • ProjectPatch — erforderlich: name
  • ProjectPlanFeature — erforderlich: id, enabled, required_plan
  • ProjectPlanFeatures — erforderlich: featuresets, features

    Die Plan-Funktionen, die das Projekt hat. Der Plan und die Featuresets des Projekts bestimmen sie; Guthaben schaltet nie eine frei. Eine Funktion, die das Projekt nicht hat, wird mit feature_not_in_plan (402) abgelehnt, dessen required_plan den niedrigsten allgemein verkauften Plan nennt, der sie enthält.

  • ProjectPlanLimits — erforderlich: screens, members, video_bytes, event_retention_days

    Die Limits des Projekts, wie Plan und Featuresets sie vorgeben, die Werte, die die Zulassungsprüfung durchsetzt. Null bedeutet keine Obergrenze des Plans.

  • ProjectUptime — erforderlich: items
  • ProvisionScreen — erforderlich: none
  • RTSPStreamSource — erforderlich: protocol, url
  • ReadyResponse — erforderlich: status, degraded
  • ReleaseLaunch — erforderlich: launch_url, expires_at
  • Report — erforderlich: kind, title, generated_at, columns, rows, truncated

    Ein Bericht als Tabelle: columns sagt, was jedes Zeilenmitglied ist. Zeilen tragen mehr Mitglieder, als die Spalten zeigen (id, parent_id und depth für die Ordnergliederung). Prozentspalten reichen von 0 bis 100.

  • ReportCatalog — erforderlich: items, formats
  • ReportColumn — erforderlich: key, label, type
  • ReportKindInfo — erforderlich: kind, title, description, params
  • ReportParam — erforderlich: name, description
  • ReportSchedule — erforderlich: cadence
  • ReportSubscription — erforderlich: id, name, kind, filters, schedule, format, enabled, recipients, revision, created_at, updated_at
  • ReportSubscriptionList — erforderlich: items
  • ReportSubscriptionPatch — erforderlich: none
  • ReportSubscriptionRecipient — erforderlich: user_id
  • ReportSubscriptionWrite — erforderlich: name, kind, schedule, format, recipients
  • Reseller — erforderlich: id, name, spread_bps, spread_effective_at, customer_count, review_state, customer_limit
  • ResellerCustomer — erforderlich: organization_id, name, plan_id, delegated_at, project_count, screen_count, stored_bytes, annual_list_cents, annual_wholesale_cents
  • ResellerCustomerPage — erforderlich: items, next_cursor
  • ResellerCustomerProject — erforderlich: id, name, status, screen_count, member
  • ResellerCustomerProjectPage — erforderlich: projects, next_cursor
  • ResellerEnrollment — erforderlich: organization_id
  • ResellerList — erforderlich: items
  • ResellerStatement — erforderlich: reseller_id, name, period, spread_bps, lines, usage_list_mcr, usage_wholesale_mcr, plan_annual_list_cents, plan_annual_wholesale_cents
  • ResellerStatementLine — erforderlich: organization_id, name, plan_id, delegated_from, project_count, screen_count, stored_bytes, api_events, usage_list_mcr, usage_wholesale_mcr, plan_annual_list_cents, plan_annual_wholesale_cents
  • ResellerSummary — erforderlich: id, name
  • Review — erforderlich: id, kind, state, subject, proposer, url, created_at, updated_at, impact
  • ReviewAdCreative — erforderlich: creative_id, creative_revision, content_path
  • ReviewApproveRequest — erforderlich: none
  • ReviewBlocker — erforderlich: id, state, subject
  • ReviewChangesRequest — erforderlich: note
  • ReviewDecider — erforderlich: none
  • ReviewDecisionResult — erforderlich: review
  • ReviewDependentResult — erforderlich: id, state
  • ReviewImpact — erforderlich: screens
  • ReviewList — erforderlich: items, next_cursor, pending_count
  • ReviewLocation — erforderlich: project_id, project_name
  • ReviewMediaChange — erforderlich: media_id, filename, before, after

    Die ausstehende Änderung eines Medienobjekts, über die eine selector_refresh-Überprüfung fragt.

  • ReviewMediaFields — erforderlich: tags, folder_id
  • ReviewMediaFile — erforderlich: sha256, bytes, content_type
  • ReviewMediaPlaylist — erforderlich: id, name, screens, media_added, media_removed
  • ReviewMediaReplace — erforderlich: media_id, filename, source, version, before, after, aspect_changed, playlists

    Der Ersatz der Datei eines Medienelements, nach dem eine media_replace-Prüfung fragt. Das Medium behält seine Datei bis zur Genehmigung.

  • ReviewPageEdit — erforderlich: op, page_id
  • ReviewPending — erforderlich: status, review

    Ein Schreibvorgang der Überprüfungsklasse mit Propose-Zugriff oder ein Schreibvorgang, der auf jeder Zugriffsstufe einen geschützten Bildschirm erreicht. Die Änderung ist erst auf dem Display, wenn eine Person die Überprüfung genehmigt; eine geschützte entscheidet eine zweite genehmigende Person (docs/screen-scope.md).

  • ReviewPerson — erforderlich: user_id, name
  • ReviewPlaylistChange — erforderlich: operation, base_revision, proposed, diff
  • ReviewPlaylistDiff — erforderlich: name_changed, pages_added, pages_removed, pages_changed, soundtrack_changed, media_added, media_removed
  • ReviewPolicy — erforderlich: agent_changes_require_review, review_policy_revision
  • ReviewPolicyUpdate — erforderlich: agent_changes_require_review
  • ReviewPreview — erforderlich: live, proposed

    Live- und vorgeschlagene Playlists in der gespeicherten Form, die GET /api/playlists/{id} zurückgibt (Seiten mit resolved_media).

  • ReviewProposer — erforderlich: kind
  • ReviewProtectedCampaign — erforderlich: none

    Ein campaign_create, campaign_update oder campaign_delete.

  • ReviewProtectedChange — erforderlich: subkind

    Der gespeicherte Input einer protected_change-Überprüfung, der über den zuständigen Dienst angewendet wird, wenn eine zweite genehmigende Person genehmigt. Genau eines von campaign, folder und move ist vorhanden, wie subkind angibt. Die Genehmigung spielt bei base_revision erneut ab; eine Kampagne oder ein Ordner, die sich weiterentwickelt haben, machen die Überprüfung veraltet (review_stale).

  • ReviewProtectedFolder — erforderlich: none

    Ein folder_create, folder_update, folder_delete oder folder_unprotect.

  • ReviewProtectedMove — erforderlich: folder_id, screen_ids, folder_ids

    Ein screens_move, der Body von POST /api/screens/move.

  • ReviewRejectRequest — erforderlich: reason
  • ReviewScreenChange — erforderlich: action, screens, request, playlist_ids
  • ReviewSubject — erforderlich: type, id, name
  • ReviewSummary — erforderlich: id, kind, state, url, subject, impact
  • RuntimeAdslotCandidate — erforderlich: page_id, occurrence_id, check_sequence, earliest_start_at
  • RuntimeAdslotEvent — erforderlich: event_id, decision_id, occurrence_id, kind, client_sequence
  • RuntimeAdslotEventBatch — erforderlich: events
  • RuntimeAdslotEventResponse — erforderlich: results
  • RuntimeAdslotEventResult — erforderlich: event_id, state
  • RuntimeAdslotMedia — erforderlich: kind, duration_ms, content_type, bytes, sha256, content_path, fit
  • RuntimeAdslotPage — erforderlich: id, type, adslot_id

    Ganzseitiger Werbeplatz, nur an eine gekoppelte Sitzung mit adslot-v1 gesendet. Ein Player, der einen unbekannten Seitentyp trifft, verwirft diese Seite.

  • RuntimeAdslotResolveRequest — erforderlich: manifest_revision, candidates
  • RuntimeAdslotResolveResponse — erforderlich: server_time, results
  • RuntimeAdslotResult — erforderlich: occurrence_id, check_sequence, state
  • RuntimeAdvance — erforderlich: mode
  • RuntimeApplicationPackage — erforderlich: version, url, bytes, sha256, entrypoint, contentType

    Unveränderliches normalisiertes Paket, das nur aus dem unabhängig validierten Anwendungssatz erstellt wird. Native Player überprüfen Bytes und SHA-256, bevor sie diese Version atomar für die Offline-Wiederherstellung des zuletzt bekannten guten Zustands speichern. Die URL ist eine autorisierungsgebundene Transportreferenz, keine öffentliche oder dauerhafte Objekt-URL.

  • RuntimeApplicationPrimitive — erforderlich: id, primitive, applicationId, releaseId, launchUrl, origin, protocol, grantId, package, rect, layer, contentFit
  • RuntimeAudio — erforderlich: loop, volume, tracks

    Playlist-Soundtrack (docs/playlist-audio.md). Wird nur abgespielt, wenn die Playlist einen hat und mindestens ein Track projiziert wird. Der Player spielt Tracks in der Reihenfolge, unabhängig vom Seiten-Sequenzer; Seitenwechsel, Übergänge und Sichtbarkeit pausieren oder starten ihn nie neu.

    Track-Identität ist id plus mediaId plus sha256, nie src, sodass eine Manifest-Aktualisierung, die den aktuell gespielten Track beibehält, ihn nicht neu startet. Effektive Lautstärke ist Volume mal Player-Lautstärke. Ein defekter Track wird eigenständig verworfen (invalid_audio_track).

  • RuntimeAudioCue — erforderlich: track, restart

    Soundtrack-Hinweis, der auf einer Seite mit audio_cue erzeugt wird. Wenn die Seite aktuell wird: Wenn ein anderer Track läuft oder keiner, wechselt er zum Track von Anfang an; wenn der Track läuft, wird er nur neu gestartet, wenn restart true ist. Die Sequenz läuft vom Track weiter. Ein Hinweis kann ignoriert werden. Ein Cue, der keinen Manifest-Track benennt, wird verworfen (invalid_audio_cue).

  • RuntimeAudioTrack — erforderlich: id, mediaId, src, sha256, bytes, contentType, durationMs, grantId
  • RuntimeCanvas — erforderlich: width, height, viewportFit, background
  • RuntimeCardPrimitive — erforderlich: id, primitive, card, major, params, rect, layer, contentFit

    Eine eingebaute Karte. Für einen Player, der CardML-Fähigkeiten deklariert, wählt das Backend die neueste kompatible veröffentlichte Revision innerhalb der festgelegten Hauptversion aus, berücksichtigt zurückgehaltene Revisionen und alle erforderlichen Funktionen; wenn keine qualifiziert, wird die Karte mit card_unavailable-Diagnosen ausgelassen und leere Seiten werden entfernt.

    Der Player kombiniert die Standardwerte der Karte, dann Parameter und bei Vorhandensein von Daten die dynamischen Eigenschaften des Dokuments bei GET /screen/card-data/{data} (nur Schlüssel, die die Karte als dynamisch markiert).

    Eine Karte mit Daten bleibt verborgen, bis ihr erstes Dokument eintrifft und blendet dann ein; screen.card_data_changed für den Schlüssel lädt sie an Ort und Stelle neu. feed, wenn vorhanden, wird von derselben Route abgerufen und als Feed an die Karte übergeben. Ein Player, dem die Karte oder ihre Hauptversion fehlt, zeichnet nichts dafür.

    Eine Zeichenkette in params oder im Daten-Dokument, die mit media: beginnt, ist eine Medienreferenz, media:<id>, die der Player in Bytes auflöst, die er hält, bevor die Karte sie zeichnet, und leer lässt, wenn dies nicht möglich ist; er übergibt niemals eine URL aus params oder Daten an eine Karte. media listet die bereiten Bild-Params-Namen auf, mit den Beschreibungen, die ein Bildprimitive resolvedMedia trägt, sodass der Player sie beim Eintreffen des Manifests herunterlädt und überprüft; eine Referenz auf Medien, die seit der Veröffentlichung nicht mehr vorhanden sind, fehlt, und die Karte zeichnet ihren Ersatz.

    Medien, die ein Datendokument nennt, stammen von /media/{media_id}, wenn das Dokument eintrifft (ETag ist der sha256). Kartenmedien halten nie eine Seite auf. Das Backend hat die Tokens {screen.name}, {screen.timezone}, {screen.field.NAME} und {screen.location} einer Platzierung für diesen Bildschirm bereits aufgelöst, sodass params und data seine eigenen Werte enthalten.

  • RuntimeChrome — erforderlich: schema_version, banner

    Laufzeit-eigenes Chrome (docs/player-compatibility.md §8). Reader lesen die ihnen bekannten Mitglieder und ignorieren den Rest; eine Bannerform, die ein Reader nicht versteht, zeigt kein Banner an.

  • RuntimeCodecs — erforderlich: none

    Serverabgeleitete RFC 6381 Codec-Liste für diese exakte Wiedergabe, niemals vom Client deklariert. Sie ist ein Geschwister von contentType; ein Player kann eine Fähigkeitsabfrage als contentType gefolgt von codecs="WERT" bilden. Ein Video, dessen Codec nicht abgeleitet werden kann, wird beim Hochladen abgelehnt. Die Eigenschaft ist optional. Ein fehlender Wert bedeutet nicht, dass der Codec nicht unterstützt wird.

    Ein aktueller Wert enthält derzeit einen Video-Track-Eintrag; die Grammatik erlaubt durch Komma getrennte Einträge.

  • RuntimeCommandResultWrite — erforderlich: state

    Der Body von POST /screen/commands/{command_id}/result. Unbekannte Mitglieder werden ignoriert (docs/player-compatibility.md §1.1).

  • RuntimeConditionReport — erforderlich: severity, code, context
  • RuntimeDisplay — erforderlich: none

    Die Display-Steuerung des Bildschirms, ausgewertet auf dem Gerät (docs/player-compatibility.md §6.5): der Stromversorgungsplan und die Überschreibung, die Einstellung für das Abdunkeln im Leerlauf und der Helligkeitsmodus. Wird weggelassen, wenn der Bildschirm keine hat; dann bleibt das Display bei der Helligkeit des Betreibers eingeschaltet. Unbekannte Mitglieder werden ignoriert.

  • RuntimeHealthWrite — erforderlich: none

    Der PUT /screen/health-Body. Jedes Mitglied ist optional; senden Sie, was die Plattform messen kann. Unbekannte Mitglieder werden ignoriert, und ein Wert außerhalb des Bereichs wird verworfen (nicht abgelehnt). Ganzzahlen sind ganze JSON-Zahlen.

  • RuntimeHostHint — erforderlich: platform

    Der optionale native Host-Hinweis beim Start des Pairings, beim Abschluss des Pairings und bei der Identitätssitzungserstellung. Er benennt ein Gerät und ist niemals eine Autorisierung.

    Sie wird tolerant gelesen (docs/player-compatibility.md §1.1.1): unbekannte Mitglieder werden ignoriert, ein fehlerhaftes Feld oder Fähigkeiten-Eintrag wird verworfen, maximal 32 Fähigkeiten werden behalten, und ein Wert, der kein Objekt ist oder eine Plattform außerhalb des Musters, verwirft den gesamten Hinweis. Keiner dieser Fälle lehnt die Anfrage ab.

    Ein Player sendet weiterhin nur die registrierten Plattformwerte und die unten aufgeführten Mitglieder, da ein Pre-Contract-Backend alles andere ablehnt.

  • RuntimeHostHintDevice — erforderlich: none

    Optionale Hardware-IDs im nativen Host-Hinweis. Ein fehlerhaftes Feld wird verworfen.

  • RuntimeIframeCookie — erforderlich: name, value, domain, path, secure, httpOnly, sameSite

    Ein Cookie eines geteilten Browser-Tabs im Format der Cookie-API des Browsers. Der Wert ist geheim.

  • RuntimeIframePrimitive — erforderlich: id, primitive, src, title, rect, layer, contentFit
  • RuntimeImagePrimitive — erforderlich: id, primitive, selector, resolvedMedia, grantId, rect, layer, contentFit
  • RuntimeImageResolvedMedia — erforderlich: mediaId, src, intrinsicSize, sha256, bytes, contentType
  • RuntimeIntrinsicSize — erforderlich: width, height
  • RuntimeKVEntry — erforderlich: application_id, key, value_base64, content_type, bytes, sha256, revision
  • RuntimeKVList — erforderlich: items
  • RuntimeKVSummary — erforderlich: application_id, key, content_type, bytes, sha256, revision
  • RuntimeKVWrite — erforderlich: value_base64
  • RuntimeKiosk — erforderlich: lock

    Die Kiosk-Sperre (docs/player-compatibility.md §6.5). Wird in jeder Sitzung ausgegeben, solange kiosk.lock des Bildschirms aktiv ist, und sonst weggelassen. Ein Player, der sich auf dem Bildschirm fixieren kann, tut das, solange lock true ist, und hebt die Fixierung auf, wenn das Mitglied fehlt oder lock false ist; einer, der es nicht kann, ignoriert es. Unbekannte Mitglieder werden ignoriert.

  • RuntimeLiveHeartbeat — erforderlich: connection

    Der eigene Bericht des Players. Offenes Schema.

  • RuntimeLiveHeartbeatAnswer — erforderlich: lease_until, max_until
  • RuntimeLiveJoin — erforderlich: live_id, ice_servers, lease_until, max_until, heartbeat_ms, video

    Wohin ein Player sendet und in welchen Grenzen. Offenes Schema.

  • RuntimeLiveJoinRequest — erforderlich: none

    Leer. Der Body kann entfallen.

  • RuntimeLiveOffer — erforderlich: sdp

    Eine Sitzungsbeschreibung ohne ihren Typ, wie das Angebot des Players und die Antwort des Relays.

  • RuntimeLiveStopped — erforderlich: reason
  • RuntimeManifest — erforderlich: schemaVersion, manifestRevision, grantId, contentGeneration, screenId, screenLabel, playlistRevision, generatedAt, pages

    Unveränderliches Laufzeitmanifest, das den deterministischen screenrig.canvas/v1 Canvas-, Rechteck-, Fit- und Quellreihenfolge-Vertrag verwendet. Zusätzliche Leseeigenschaften sind erlaubt, sodass ein Player bei diesem Vertrag unbekannte Schlüssel ignoriert (Kompatibilitätsregel 2). Schreibschemata bleiben geschlossen.

    Seiten sind gewöhnliche Canvas-Seiten und für eine gekoppelte Sitzung mit granted adslot-v1 ganze Seiten mit Werbeplätzen; ein Manifest ohne Werbeplatzseite ist Hausinhalt.

  • RuntimeManifestDiagnostic — erforderlich: level, code, detail

    Eine ausfallsichere Laufzeit-Projektionsauslassung. Player und CLI können diese anzeigen; sie sind niemals Autorisierung.

  • RuntimeMediaSelector — erforderlich: none
  • RuntimeMediaSelectorByAll — erforderlich: by, oneAtATime
  • RuntimeMediaSelectorByID — erforderlich: by, mediaId, oneAtATime
  • RuntimeMediaSelectorByIDs — erforderlich: by, mediaIds, oneAtATime
  • RuntimeMediaSelectorByTag — erforderlich: by, oneAtATime
  • RuntimeObservationSurfaceWrite — erforderlich: id, width, height, pixel_ratio, presentation
  • RuntimeObservationWrite — erforderlich: observed_at, surfaces

    Der PUT /screen/observation-Body. Unbekannte Mitglieder werden ignoriert (docs/player-compatibility.md §1.1). Der gespeicherte Wert ist die Projekt-ScreenObservation.

  • RuntimeOrigins — erforderlich: content

    Die gelieferte Origin-Allowlist (docs/player-compatibility.md §2.3). Nur bei einer Mint-Antwort für einen Player mit granted origins-v1 vorhanden.

    Der Player vereinigt Inhalte mit seinen kompilierten Inhaltsquellen und ignoriert ungültige Einträge. release_suffix ersetzt den kompilierten Release-Suffix nur, wenn es ein gültiger DNS-Suffix mit mindestens zwei Labels ist; er fehlt, wenn der Laufzeit-Ursprung Releases selbst bereitstellt (lokale Entwicklung).

    Das gelieferte Set ändert niemals die Credential-Origin, und das Backend setzt niemals eine URL auf eine Origin, die diese Sitzungsmint nicht geliefert hat. Ein Player speichert das Objekt, das es zuletzt als last-known-good validiert hat, sodass eine spätere Sitzung ohne Origins dieses LKG gültig hält.

  • RuntimePage — erforderlich: contractVersion, id, canvas, transition, advance, primitives
  • RuntimePairingScreen — erforderlich: id, public_id, label, state, revision, manifest_revision, content_access_generation, created_at, updated_at

    Laufzeit-eigene Bildschirmzusammenfassung bei Kopplungs- und Browserbereitstellungen. Die Mitgliedermenge ist eingefroren: Projekt-Bildschirmfelder erscheinen hier nie (docs/player-compatibility.md §8). Der Zustand bleibt innerhalb der drei untenstehenden Werte.

  • RuntimePrimitive — erforderlich: none
  • RuntimeProblem — erforderlich: type, title, status, detail, instance, code, request_id, errors

    Das Problemdokument der Player-gerichteten Bildschirm- (/screen/) und Medien- (/media/) Routen, der Pairing-Streams und der Probe-Routen (/.ready, /.health): alle Mitglieder flach auf oberster Ebene. Store-veröffentlichte Player lesen dessen oberste Code- und Action-Felder (docs/player-compatibility.md §5), daher bleibt diese Form unverändert; alle anderen Routen antworten mit Problem.

  • RuntimeRect — erforderlich: x, y, width, height
  • RuntimeReport — erforderlich: none

    Meldungen und Kontexte werden tolerant gelesen (docs/player-compatibility.md §1.1). Ein Code benötigt eigene Kontextmitglieder; andere Mitglieder werden ignoriert. Player senden weiterhin nur die untenstehenden Mitglieder, da ein Pre-Contract-Backend andere ablehnt.

  • RuntimeScreenLabel — erforderlich: screen_label

    Der gespeicherte Bildschirmname, der Wert, den das Manifest als screen_label trägt.

  • RuntimeScreenLabelWrite — erforderlich: screen_label

    Der PUT /screen/screen-label-Body. Der Server entfernt führende und nachfolgende Leerzeichen aus screen_label und speichert 1 bis 120 Zeichen ohne Steuerzeichen. Unbekannte Mitglieder werden ignoriert (docs/player-compatibility.md §1.1).

  • RuntimeScreenPlaylist — erforderlich: playlist_id

    Die dem Bildschirm nach der Änderung zugewiesene Playlist.

  • RuntimeScreenPlaylistWrite — erforderlich: playlist_id

    Der PUT /screen/playlist-Body. Unbekannte Mitglieder werden ignoriert (docs/player-compatibility.md §1.1).

  • RuntimeScreenPlaylists — erforderlich: playlists, more

    Die Playlists, die ein Bildschirm im Gerät auswählbar anbietet, alphabetisch nach Name ohne Berücksichtigung der Groß-/Kleinschreibung, dann nach ID.

  • RuntimeSelectorPlaylistSnapshot — erforderlich: selections, pageMaxMs

    Die Auswahlen einer Stack-Playlist, benannt nach den eigenen Seiten-IDs dieser Playlist.

  • RuntimeSelectorSnapshot — erforderlich: manifestRevision, snapshotRevision, selections, pageMaxMs
  • RuntimeSession — erforderlich: paired, capabilities, event_cursor, public_url

    Laufzeit-eigene Sitzung (docs/player-compatibility.md §8). Reader ignorieren unbekannte Mitglieder und unbekannte Fähigkeitswerte. Ein neues Mitglied wird nur an Sitzungen gesendet, deren Berechtigungen es abdecken.

  • RuntimeSessionRequest — erforderlich: public_id

    Anonymer Betrachter-Mint. Unbekannte Mitglieder werden ignoriert (docs/player-compatibility.md §1.1).

  • RuntimeStack — erforderlich: levels, playlists

    Jede Ebene des Stapels des Bildschirms, nur an einen Player gesendet, der die Host-Fähigkeit schedule.stack deklariert hat, und nur wenn der Stapel mehr als eine Ebene hat (docs/player-compatibility.md §6.11). Die Stammfelder des Manifests sind die Playlist der untersten Ebene; der Player löst die Ebenen selbst mit dem Zeitplanvertrag auf.

  • RuntimeStackPlaylist — erforderlich: playlistRevision, pages
  • RuntimeStatusWrite — erforderlich: observed_at, chip

    Der PUT /screen/status-Body. Unbekannte Mitglieder werden ignoriert (docs/player-compatibility.md §1.1). Der gespeicherte Wert ist der Projekt-ScreenStatus.

  • RuntimeStorageWrite — erforderlich: observed_at, volume, cache, durability, plan, transfer_24h

    Der PUT /screen/storage-Body. Unbekannte Mitglieder werden ignoriert (docs/player-compatibility.md §1.1). Der gespeicherte Wert ist das Projekt ScreenStorage plus serverseitiges received_at.

  • RuntimeStreamPrimitive — erforderlich: id, primitive, sources, muted, fallback, grantId, rect, layer, contentFit
  • RuntimeSuspension — erforderlich: message, since

    Wird gesendet, solange der Bildschirm ausgesetzt ist (docs/player-compatibility.md §6.9): pages ist [] ohne Diagnosen, und ein Player zeigt message als Vollbild-Mitteilung anstelle der Anzeige ohne Inhalt. since gibt an, wann der Bildschirm erstmals ausgesetzt wurde. Die Manifestrevision gehört der Mitteilung selbst, nie einer Playlist, und der Bildschirm benötigt keine zugewiesene Playlist.

  • RuntimeTelemetryBatch — erforderlich: telemetry_epoch, stream_id, sequence, created_at, reports

    Eine dauerhafte FIFO-Player-Warteschlange sendet höchstens ein gewöhnliches Paket pro Minute mit zufälliger Phase oder früher, wenn sie voll ist. Der gesamte JSON-Body ist höchstens 256 KiB; höchstens 64 Berichte, jeder höchstens 32 KiB. Jeder Bericht behält seinen Zeitstempel und eine stabile play_id.

    Behalten Sie eine unveränderliche laufende Charge auf der Festplatte bis 202, erhöhen Sie die Sequenz nur nach Bestätigung und wiederholen Sie dieselben Bytes nach verlorenen Antworten oder Neustarts. Die Sequenz beginnt bei 1 und hat keine Lücken.

    Dedupe behält höchstens acht Live-Streams pro Bildschirm, jedes Wasserzeichen mindestens für die 24 Stunden, in denen seine Charge noch wiedergegeben werden kann; denselben Stream bei Anmeldeinformationen-Erneuerung beibehalten. Datensätze verfallen lokal nach 24 Stunden mit expliziter Abrechnung. manifest.activated und manifest.upgrade bleiben individuell und unmittelbar.

    Interaktive Schreibvorgänge, Anzeigenauflösung, Inhaltsabrufe, Screenshots und SDK emitConfirmed() bleiben ebenfalls unmittelbar. Die Gesundheitsabfrage behält ihr fünfzehnminütiges Intervall bei; dringende Anzeige-/Gesundheitsübergänge werden sofort gesendet. Beobachtungen und gewöhnliche Gesundheits-Snapshots sind aktuell mit den ursprünglichen Zeitpunkten. Für Gesundheit ist health.write erforderlich.

    Vorhandene Einzelberichte werden weiterhin akzeptiert. Missbrauchsgrenzen für Berichtselemente gelten pro neuem Element und nicht pro HTTP-Umschlag; festgeschriebene Wiedergabe verbraucht nur die Anforderungszulassung.

  • RuntimeTransition — erforderlich: type, durationMs

    Erstellte Seitenübergänge. Einfache Bewegungen behalten Schriftart, Dauer und optionale Dekorationen bei. Stinger trägt die normale Karteninhaltsform über beiden Ebenen. Fehlender Code oder ein inkompatibler Player-Interpreter reduziert nur den Übergang auf eine Überblendung mit derselben Dauer, mit Diagnosemeldung transition_unavailable.

  • RuntimeTransitionCard — erforderlich: primitive, card, major, params, version, src, sha256, model, requires

    Dasselbe projizierte Karteninhalt wie eine Canvas-Karte, ohne Canvas-Platzierungsgeometrie. Stinger ist an Major 1 fixiert; params enthält durationMs und hangMs.

  • RuntimeUpgradeNotice — erforderlich: state, player_kind, recommended

    Bei einer mint-Antwort vorhanden, wenn die vergleichbare Version des Players unter der empfohlenen Version für player_kind liegt (docs/player-compatibility.md §6.1). Der Player startet eine Plattform-Update-Prüfung und zeigt nichts auf dem Bildschirm. Ein Leser ignoriert das Mitglied für einen Zustand, den er nicht kennt.

  • RuntimeVerbosity — erforderlich: none

    Die niedrigste Log-Stufe und Toast-Stufe, die der Player erzeugt und anzeigt (docs/player-compatibility.md §6.12). Wird in jeder Sitzung gesendet, wenn der Bildschirm eine von beiden setzt; jedes Mitglied entfällt, wenn es nicht gesetzt ist. Fehler werden immer erzeugt und angezeigt. Ein Player ignoriert ein unbekanntes Mitglied oder einen unbekannten Wert und behält seine Vorgabe.

  • RuntimeVideoPrimitive — erforderlich: id, primitive, selector, resolvedMedia, muted, loop, grantId, rect, layer, contentFit
  • RuntimeVideoResolvedMedia — erforderlich: mediaId, src, intrinsicSize, sha256, bytes, contentType
  • RuntimeWall — erforderlich: outputs, arrangement, rotation, span

    Die Videowand des Bildschirms, wie sie sein Player anordnet (docs/player-compatibility.md §6.8). Wird nur gesendet, wenn der Bildschirm eine Wand hat. Unbekannte Mitglieder werden ignoriert.

  • SCIMError — erforderlich: schemas, status

    Das Fehlerdokument nach RFC 7644 Abschnitt 3.12.

  • SCIMEvent — erforderlich: at, action, status
  • SCIMEventList — erforderlich: events
  • SCIMGroupList — erforderlich: groups
  • SCIMGroupProjectBinding — erforderlich: binding_id, project_id, project_name, role
  • SCIMGroupSummary — erforderlich: id, display_name, member_count, bindings
  • SCIMResource — erforderlich: none

    Ein SCIM-2.0-Dokument in der Form, die RFC 7643 und RFC 7644 an der Route vorgeben, die es trägt; jede Operation nennt, welches es ist. Es ist eine User- oder Group-Ressource, eine ListResponse, eine PatchOp-Nachricht, eine ServiceProviderConfig, ein ResourceType oder ein Schema. Felder, die screenRIG nicht verwendet, werden akzeptiert und ignoriert.

  • SCIMSettings — erforderlich: enabled, base_url, tokens, user_count, group_count
  • SCIMSettingsWrite — erforderlich: enabled, proof
  • SCIMToken — erforderlich: id, name, prefix, created_at
  • SCIMTokenCreate — erforderlich: name, proof
  • SCIMTokenCreated — erforderlich: id, name, prefix, created_at, token

    Ein SCIMToken mit seinem Secret, einmalig zurückgegeben.

  • SSODiscovery — erforderlich: sso, required, account

    Wie sich die Adresse anmeldet oder registriert. sso, required und provider_name werden allein von der Domain der Adresse bestimmt; account gibt an, ob eine aktive Person die Adresse besitzt.

  • SSODiscoveryRequest — erforderlich: email
  • SSOErrorCode — erforderlich: none

    Der stabile Code, mit dem eine Single-Sign-on-Anmeldung endet, wenn sie nicht abgeschlossen wird: der Wert von #sso_error= in der Adresse, zu der POST /api/sso/finish weiterleitet, und der Code eines fehlgeschlagenen Identitätsanbieter-Tests. no_email: Der Anbieter hat keine E-Mail-Adresse angegeben. email_unverified: Er hat die Adresse als unverifiziert markiert. domain_not_allowed: Die Adresse liegt nicht an einer der verifizierten Domains der Organisation. account_exists: Die Adresse gehört bereits zu einem Konto mit eigener Anmeldung; die Person meldet sich wie bisher an und verknüpft die Identität von ihrem Konto aus (intent link). managed_elsewhere: Eine andere Organisation verwaltet die Person. subject_mismatch: Das Konto ist mit einer anderen Identität beim selben Anbieter verknüpft. not_provisioned: Niemand besitzt die Adresse, und die Verbindung legt keine Personen an. sso_required: Die Organisation verlangt Single Sign-on für die Adresse. staff_account: Ein Mitarbeiterkonto von screenRIG wird vom Identitätsanbieter eines Kunden nie angemeldet, übernommen oder verknüpft. expired: Die Anmeldung hat ihre 10 Minuten überschritten. bad_state: Der state der Anmeldung oder die Browserbindung stimmt nicht überein, oder sie wurde bereits verwendet. interaction_required: Eine stille Erneuerung braucht die Person. provider_refused: Der Anbieter hat mit einem Fehler geantwortet. provider_unavailable: Der Anbieter war nicht erreichbar oder nicht lesbar. verification_failed: Das Token oder die Assertion des Anbieters hat die Verifizierung nicht bestanden. deactivated: Die Person ist deaktiviert.

  • SSOPolicy — erforderlich: required, break_glass_user_ids, passkey_admin_ids, policy_revision
  • SSOPolicyWrite — erforderlich: required, break_glass_user_ids, proof
  • SSOStart — erforderlich: redirect_url
  • SSOStartRequest — erforderlich: email
  • SSOTestStart — erforderlich: redirect_url
  • ScheduleCalendar — erforderlich: subject, from, to, screens, groups
  • ScheduleCalendarConflict — erforderlich: kind, level_ids
  • ScheduleCalendarGroup — erforderlich: key, screens, screen_ids, displays, levels, spans, on_screen, conflicts
  • ScheduleCalendarOnScreen — erforderlich: display, from, to
  • ScheduleCalendarSpan — erforderlich: level_id, from, to, state
  • ScheduleImportCommitted — erforderlich: preview, applied
  • ScheduleImportLevel — erforderlich: key, action, home, content, screens, priority, rows
  • ScheduleImportPreview — erforderlich: name, columns, valid, fingerprint, summary, rows, levels, removals
  • ScheduleImportRemoval — erforderlich: home
  • ScheduleImportRequest — erforderlich: rows
  • ScheduleImportResolved — erforderlich: kind, id, name
  • ScheduleImportRow — erforderlich: row, status
  • ScheduleImportRowError — erforderlich: code, message
  • ScheduleImportSummary — erforderlich: rows, rows_with_errors, levels, creates, updates, unchanged, removes, screens, playlists
  • SchedulePreview — erforderlich: gained, lost, calendar

    Was ein Schreibvorgang an einer Kampagne oder einem Zeitplan ändern würde. gained sind die Bildschirme, die eine Ebene des Schreibvorgangs tragen würden, die sie jetzt nicht tragen, lost die, die eine tragen, die sie nicht mehr tragen würden; eine Ebene, die auf einem Stack bleibt, ändert keines von beiden und erscheint in calendar.

  • SchedulePreviewReach — erforderlich: count, screen_ids
  • Screen — erforderlich: id, public_id, label, revision, manifest_revision, manifest_upgrade, content_access_generation, state, online, created_at, updated_at
  • ScreenAction — erforderlich: none

    Eine Flottenaktion, unterschieden nach Typ. Jedes Mitglied trägt nur seine eigenen Parameter; ein Mitglied eines anderen Typs ist ein unbekanntes Feld und invalid_request.

  • ScreenActionAddTags — erforderlich: type, tags

    Fügt Tags hinzu, die ein Bildschirm noch nicht trägt. Ein Bildschirm, der mehr als 16 Tags hätte, schlägt mit invalid_request fehl.

  • ScreenActionAssign — erforderlich: type, playlist_id
  • ScreenActionClearDisplaySchedule — erforderlich: type

    Entfernt den Anzeigzeitplan jedes Bildschirms; ein Bildschirm ohne Zeitplan ist in Ordnung und unverändert.

  • ScreenActionClearPlaylist — erforderlich: type

    Entfernt die eigene Standard-Playlist jedes Bildschirms und behält die Kopplung und die übrigen Inhaltsebenen. Ohne wirksamen Inhalt zeigt der Player seine Ruheanzeige. Prüfpflichtig wie das Zuweisen.

  • ScreenActionClearPlaylistSchedule — erforderlich: type

    Entfernt den Playlist-Zeitplan jedes Bildschirms; ein Bildschirm ohne Zeitplan ist in Ordnung und unverändert.

  • ScreenActionClearRebootSchedule — erforderlich: type

    Entfernt den Neustartplan jedes Bildschirms; ein Bildschirm ohne Neustartplan ist in Ordnung und unverändert. Nur mit Manage-Zugriff.

  • ScreenActionDisplay — erforderlich: type, power

    Gleiche Regeln wie ScreenDisplayWrite. until wird gegen die Anforderungsuhr geprüft, wenn Idempotency-Key keinen Flotteneintrag hat, und erneut von jedem Bildschirm.

  • ScreenActionDisplayClear — erforderlich: type

    Beendet die manuelle Anzeigeüberschreibung jedes Bildschirms (DELETE /api/screens/{id}/display); ein Bildschirm ohne Überschreibung ist in Ordnung und bleibt unverändert.

  • ScreenActionMaintenance — erforderlich: type

    POST /api/screens/{id}/clear-cache, /restart-app oder /update pro Bildschirm; ein Bildschirm, dessen Host die Fähigkeit nicht gemeldet hat, schlägt allein mit command_unsupported fehl. Ein Offline-Bildschirm hält den Befehl als queued, bis er online geht (expires_in_s).

  • ScreenActionReboot — erforderlich: type

    POST /api/screens/{id}/reboot pro Bildschirm; ein Bildschirm, dessen Host reboot nicht deklariert hat, schlägt allein mit reboot_unsupported fehl. Ein Offline-Bildschirm hält den Neustart in der Warteschlange, bis er online geht (expires_in_s).

  • ScreenActionReload — erforderlich: type

    POST /api/screens/{id}/reload pro Bildschirm. Ein Offline-Bildschirm hält das Neuladen in der Warteschlange, bis er online geht (expires_in_s).

  • ScreenActionRemoveTags — erforderlich: type, tags

    Entfernt die aufgelisteten Tags; ein Tag, den der Bildschirm nicht trägt, wird ignoriert.

  • ScreenActionRequest — erforderlich: selector, action
  • ScreenActionResult — erforderlich: action, matched, succeeded, failed, results
  • ScreenActionScreenResult — erforderlich: screen_id, status

    Das Ergebnis eines Bildschirms. ok trägt das Ergebnis des Einzelbildschirmpfads: revision (und tags bei Tag-Aktionen) für die Aktionen assign, tag, takeover, takeover_clear, set_playlist_schedule, clear_playlist_schedule, set_reboot_schedule und clear_reboot_schedule, reload für reload, toast für toast. failed trägt das Problem, das die eigene Anfrage dieses Bildschirms beantwortet hätte.

  • ScreenActionSelector — erforderlich: none
  • ScreenActionSelectorFolder — erforderlich: by, folder_id

    Jeder aktive Bildschirm im Bildschirmordner und in jedem darin enthaltenen Ordner, in Erstellungsreihenfolge. Es gibt keine Begrenzung der Bildschirmanzahl.

  • ScreenActionSelectorIds — erforderlich: by, screen_ids
  • ScreenActionSelectorTag — erforderlich: by, tag

    Jeder aktive Bildschirm, dessen Tags tag enthalten, in Erstellungsreihenfolge. Es gibt keine Begrenzung der Bildschirmanzahl.

  • ScreenActionSetDisplaySchedule — erforderlich: type, enabled, windows

    Ersetzt den Display-Zeitplan jedes Bildschirms (ScreenDisplayScheduleWrite), einmal normalisiert vor der Verteilung. Ein Bildschirm ohne Zeitzone schlägt einzeln mit invalid_request fehl.

  • ScreenActionSetPlaylistSchedule — erforderlich: type, entries

    Ersetzt den Playlist-Zeitplan jedes Bildschirms mit denselben Einträgen (ScreenPlaylistScheduleWrite). Eintrags-IDs werden einmal vor der Verteilung vergeben. Ein Bildschirm ohne Zeitzone oder ohne Standard-Playlist schlägt einzeln mit invalid_request fehl.

  • ScreenActionSetRebootSchedule — erforderlich: type, enabled, windows

    Ersetzt den Neustartplan jedes Bildschirms (ScreenRebootScheduleWrite), einmal normalisiert vor der Verteilung. Nur mit Manage-Zugriff. Ein Bildschirm ohne Zeitzone schlägt einzeln mit invalid_request fehl, und einer, dessen Player reboot nicht deklariert hat, mit reboot_unsupported.

  • ScreenActionSetTags — erforderlich: type, tags

    Ersetzt das Tag-Set jedes Bildschirms; ein leeres Array löscht es.

  • ScreenActionTakeover — erforderlich: type, playlist_id

    Gleiche Regeln wie ScreenTakeoverWrite. until wird vor der Verteilung gegen die Anforderungsuhr geprüft, wenn Idempotency-Key keinen Flotteneintrag hat, und erneut von jedem Bildschirm.

  • ScreenActionTakeoverClear — erforderlich: type

    Beendet die Übernahme jedes Bildschirms; ein Bildschirm ohne Übernahme ist in Ordnung und bleibt unverändert.

  • ScreenActionToast — erforderlich: type, level, text

    Gleiche Regeln für Level, Text und Dauer wie bei ScreenToastWrite, einmal vor der Verteilung validiert.

  • ScreenCampaigns — erforderlich: screen_id, items
  • ScreenCommand — erforderlich: id, type, state, requested_at, expires_at

    Ein Neustart-, Neulade-, clear_cache-, restart_app- oder update-Befehl, der an einen Bildschirm gerichtet wurde, in Screen.commands. Ein an einen Online-Bildschirm gesendeter Befehl wird als sent gespeichert.

    Ein an einen Offline-Bildschirm gerichteter Befehl wird als queued ohne Laufzeitereignis gespeichert; das Backend hängt das Ereignis mit dieser ID und expires_at an, wenn es den nächsten Online-Übergang des Bildschirms vor expires_at anwendet, und der Befehl wird zu sent.

    Jeder Befehl hat genau ein Laufzeitereignis, sodass ein Player ihn nicht zweimal sieht. expired wird beim Lesen für einen Befehl in der Warteschlange abgeleitet, dessen expires_at überschritten ist. Ein neuerer Befehl desselben Typs ersetzt einen, der noch in der Warteschlange steht. Ein gesendeter Neustart wird zu done, wenn ein Zustandsbericht mit uptime_s zeigt, dass der Start nach sent_at lag; ein Neuladen erreicht nie done.

    Ein Befehl clear_cache, restart_app oder update wird zu done oder failed, sobald sein Player ihn mit Ursache und Detail meldet.

  • ScreenCommandPage — erforderlich: items, next_cursor
  • ScreenCommandWrite — erforderlich: none

    Der optionale Body von POST /api/screens/{id}/reboot, /reload, /clear-cache, /restart-app und /update. Ein leerer Body behält den Standard.

  • ScreenDeviceSettingsPatch — erforderlich: none

    Eine Änderung der Einstellungen eines Bildschirms für das Abdunkeln im Leerlauf und die Helligkeit sowie seiner Kiosk-Sperre (patchScreenDeviceSettings). Der Body nennt mindestens eines der beiden Mitglieder und kein anderes.

  • ScreenDisplay — erforderlich: requested, source

    Zustand der Display-Stromversorgung. requested ist, was der Bildschirm jetzt anzeigen soll: die aktive Überschreibung, sonst der aktivierte Anzeigeplan, ausgewertet in der Zeitzone des Bildschirms, sonst on (Quelle override, schedule oder default); until ist, wann sich das als Nächstes ändert, falls bekannt. reported ist die letzte Gesundheitsanzeige des Players (power, connected, reported_at, nach 35 Minuten veraltet). idle und brightness sind die Einstellungen display.idle und display.brightness des Bildschirms (gesetzt durch ScreenPatch).

    Abwesend, wenn der Bildschirm keinen Zeitplan, keine Überschreibung, keine Einstellung für Leerlauf oder Helligkeit und keine gemeldete Anzeige hat.

  • ScreenDisplayBrightness — erforderlich: mode

    display.brightness: auto bildet das Umgebungslicht des Geräts auf die Fensterhelligkeit ab; fixed (der Standard) behält die Helligkeit des Betreibers bei. Wird von einem Player angewendet, der die Host-Fähigkeit brightness.auto deklariert, was er nur deklariert, wenn das Gerät einen Lichtsensor hat.

  • ScreenDisplayIdle — erforderlich: after_s, wake

    display.idle: Der Bildschirm wird nach after_s Sekunden ohne Berührung, Tastendruck oder, wenn wake presence aufführt, ohne dass jemand vor dem Bildschirm steht, dunkel (die Kamera des Geräts, auf dem Gerät analysiert; kein Bild verlässt es). Ein Aufweckereignis schaltet ihn sofort wieder ein, und die Berührung, die einen dunklen Bildschirm aufweckt, wird verbraucht.

    Solange der Bildschirm dunkel ist, ist der Player im Zustand „Display aus“, wie bei einem Anzeigeplan: Er hält die Wiedergabe an (keine Wiedergaben, keine Werbung), meldet in seinem Gesundheitsbericht display.power off und setzt sie beim Aufwecken fort. Ein Anzeigeplan oder eine Überschreibung, die das Panel ausgeschaltet hält, hat Vorrang, und eine Anwendung, die device.display hält, hat Vorrang vor idle, solange ihre Seite auf dem Bildschirm ist.

    Wird von einem Player angewendet, der die Host-Fähigkeit display_power.idle deklariert.

  • ScreenDisplayOverride — erforderlich: override_id, power, until, ends_at, set_at
  • ScreenDisplayPatch — erforderlich: none
  • ScreenDisplayReported — erforderlich: reported_at, stale

    Der letzte Zustandsbericht des Displays des Players. Beobachtete Stromversorgung und Konnektivität, unabhängig von der angeforderten Stromversorgung. stale ist nach 35 Minuten ohne Bericht wahr; das ist Kontext, kein Beweis, dass die Stromversorgung einen Screenshot-Fehler verursacht hat.

  • ScreenDisplaySchedule — erforderlich: enabled, windows, updated_at
  • ScreenDisplayScheduleView — erforderlich: display_schedule
  • ScreenDisplayScheduleWrite — erforderlich: enabled, windows
  • ScreenDisplayWrite — erforderlich: power
  • ScreenEffectivePlaylist — erforderlich: id, source

    Die Playlist, aus der das Laufzeitmanifest des Bildschirms erstellt wird: die Übernahme, sonst die erste zutreffende Kampagne (entry_id ist die Kampagnen-ID), sonst der erste passende Playlist-Zeitplaneintrag (entry_id), sonst die zugewiesene Standard-Playlist, sonst die Standard-Playlist des nächstgelegenen Ordners, der den Bildschirm enthält (source folder, entry_id ist die Ordner-ID). until ist der nächste Zeitpunkt, an dem sich dies bekanntermaßen ändert (Ende der Übernahme oder die nächste Zeitplan-Grenze innerhalb von acht Tagen), fehlt, wenn sich nichts Zeitbasiertes ändert.

    Der Boundary-Worker wendet eine Änderung höchstens 60 Sekunden verspätet an. Eine Übernahme oder ein Eintrag, dessen Playlist nicht angezeigt werden kann, wird übersprungen. Fehlend, wenn der Bildschirm keine Playlist zeigt.

  • ScreenExplainAt — erforderlich: instant, effective_playlist, verdicts, not_judged

    Was der Bildschirm zu instant zeigt und warum, nach dem Resolver, den der Grenzdurchlauf ausführt. Übernahme, Playlist-Zeitplan des Bildschirms und die Kampagnen des Projekts werden so gelesen, wie sie jetzt sind, nicht wie sie damals waren. Eine Kampagne, deren Playlist fehlt oder nicht freigegeben ist, wird übersprungen, wie der Durchlauf sie überspringt.

    Auf einem Bildschirm, dessen Player seinen eigenen Stapel auflöst (schedule.stack), lesen die Bewertungen diesen Stapel, und not_judged weist darauf hin (player_stack).

  • ScreenFieldsPatch — erforderlich: fields

    Eine Änderung der Felder eines Bildschirms (patchScreenFields). Der Body hat kein anderes Mitglied.

  • ScreenFolder — erforderlich: id, name, parent_id, revision, created_at, updated_at

    Ein Bildschirmordner. Ein Bildschirm befindet sich in höchstens einem Ordner (Screen.folder_id); ein Ordner spricht seine Bildschirme und die jedes darin enthaltenen Ordners gezielt an.

  • ScreenFolderCreate — erforderlich: name
  • ScreenFolderDeleteResult — erforderlich: levels
  • ScreenFolderList — erforderlich: items
  • ScreenFolderPatch — erforderlich: none
  • ScreenGlass — erforderlich: none

    Was das Backend aus den empfangenen Meldungen über das Bild des Bildschirms geschlossen hat, nie aus dem, was der Player über sich selbst sagt. Eine Prüfung, die nichts zu sagen hat, lässt ihr Mitglied weg. In der Projekt-API nur lesbar. Nie eine Autorisierung oder Zulassung. ScreenPatch kann es nicht schreiben.

  • ScreenGlassChangedDetails — erforderlich: check, verdict, previous, since, evidence

    Details-Objekt bei einem dauerhaften, nur projektbezogenen screen.glass_changed-Ereignis, das angehängt wird, wenn eine Glasprüfung ihr Urteil für einen Bildschirm ändert. Es ist kein Laufzeit-Zielgruppenbefehl und wird nicht über GET /screen/events zugestellt.

    Die Bedingung loop_stalled wird bei einem Wiedergabeurteil stalled geöffnet und bei jedem anderen beendet; glass_blank und glass_frozen werden bei einem Bildurteil blank oder frozen geöffnet und bei jedem anderen beendet.

  • ScreenHealth — erforderlich: reported_at, stale

    Der neueste Geräte-Gesundheitsbericht (PUT /screen/health), bereinigt, mit serverseitigem reported_at. Ein Mitglied, das der Player nicht gesendet hat, fehlt. stale ist true, wenn reported_at älter als 35 Minuten ist; veraltete Gesundheitsdaten werden weiterhin angezeigt, nie gelöscht; Archivierung und Bildschirmwiederherstellung löschen sie.

    Übergänge fügen das nur im Projekt verfügbare screen.health_changed mit details.changes hinzu, eine Liste von {change, ...}: display_disconnected, display_reconnected, display_power (from, to), temperature_high (bei oder über 80 °C), temperature_normal (wieder unter 75 °C), on_battery (battery.source wurde none; level_percent, wenn gemeldet) und plugged_in (wieder eine andere Quelle; source), crash_spike und renderer_restart_spike (die 24-Stunden-Anzahl stieg seit dem letzten Spike-Ereignis um 3 oder mehr; crashes_24h oder renderer_restarts_24h und previous). battery ist nur vorhanden, wenn das Gerät einen Akku meldet; das Backend liest daraus nichts außer battery.source für die Bedingung on_battery und leitet keine Ursache ab.

    Nur lesend; niemals Autorisierung.

  • ScreenHealthHistory — erforderlich: none

    Eine Seite mit Berichten (Auflösung Rohdaten) oder stündlichen Zusammenfassungen (Auflösung Stunde).

  • ScreenHealthHour — erforderlich: hour, reports, temperature_max_c, temperature_avg_c, cpu_load_max, memory_used_ratio_max, wifi_rssi_min_dbm, display_disconnected, crashes_24h_max, renderer_restarts_24h_max, last_reported_at

    Berichte eines Bildschirms in einer UTC-Stunde. Ein Mitglied ist null, wenn kein Bericht der Stunde es enthielt.

  • ScreenHealthHours — erforderlich: resolution, hours, next_cursor
  • ScreenHealthSample — erforderlich: reported_at

    Ein gespeicherter Geräte-Gesundheitsbericht: Screen.health ohne veraltete Daten und ohne cpu.utilization_percent und cpu.app_percent, die nur der neueste Bericht (Screen.health) enthält. Ein Mitglied, das der Player nicht gesendet hat, fehlt.

  • ScreenHealthSamples — erforderlich: resolution, samples, next_cursor
  • ScreenIdentifyAccepted — erforderlich: identify_id, duration_ms, expires_at
  • ScreenIdentifyDetails — erforderlich: identify_id, label, screen_id, duration_ms, at, expires_at

    Details-Objekt bei einem dauerhaften player.identify-Ereignis.

  • ScreenIdentifyWrite — erforderlich: none
  • ScreenKiosk — erforderlich: lock

    kiosk.lock: Der Player fixiert sich auf dem Bildschirm (Android-Bildschirmfixierung mit startLockTask; die Person am Bildschirm bestätigt es beim ersten Mal, und Statusleiste, Home und Übersicht sind blockiert, solange fixiert ist; die verwaltete Variante als Geräteeigentümer behält ihren Lock-Task). Nur vorhanden, solange die Sperre aktiv ist.

    Das Operator-Einstellungsfeld bietet „Kiosk-Sperre verlassen“ an, was die Fixierung aufhebt, bis das nächste Manifest oder ein Neustart sie wieder anwendet. Wird von einem Player angewendet, der die Host-Fähigkeit kiosk_lock deklariert.

  • ScreenKioskPatch — erforderlich: lock
  • ScreenLevelChange — erforderlich: source, id, playlist_id, screens
  • ScreenLevelChanges — erforderlich: gained, lost

    Was ein Schreibvorgang mit den Zeitplänen der Bildschirme macht, die er ändert: die Kampagnen, in deren Zielgruppe sie eintreten (gained) oder die sie verlassen (lost), und die Standard-Playlists von Ordnern, die ihre Standard-Playlist werden oder es nicht mehr sind. screens zählt die betroffenen Bildschirme pro Ebene.

    Bei einem Tag-Schreibvorgang meldet ein Kampagneneintrag die Zugehörigkeit zur Zielgruppe: jede aktive Kampagne, in die die Bildschirme eintreten oder die sie verlassen, unabhängig davon, ob sie dort spielt, was von der Standard-Playlist des Bildschirms abhängt. Ein Verschieben oder eine Ordneränderung listet die Kampagnen auf, deren Ordner-Zielgruppe sich auf Bildschirmen verschiebt, die sie spielen.

  • ScreenLinkSessionRequest — erforderlich: screen_link

    Das Geheimnis des Bildschirmlinks plus die optionalen Hinweise host, playback und player. Unbekannte Mitglieder werden ignoriert, und host, playback und player werden tolerant gelesen (docs/player-compatibility.md §1.1). Das Geheimnis ist eine Anmeldeinformation: Es wird nie protokolliert oder zurückgegeben.

  • ScreenLinkSummary — erforderlich: hint, created_at

    Der Link des Bildschirms, ohne seine url. Nur vorhanden, solange der Bildschirm einen Link hat. Schreibgeschützt; POST und DELETE /api/screens/{id}/link ändern ihn.

  • ScreenList — erforderlich: items
  • ScreenLocation — erforderlich: latitude, longitude

    Wo sich ein Bildschirm befindet, in Dezimalgrad, mit einem optionalen kurzen Ortsnamen und einer Straßenadresse. Eine Kartenplatzierung liest den Standort über das Token {screen.location}, und die Bildschirmliste filtert nach dem Abstand von einem Punkt (near).

  • ScreenLocationPatch — erforderlich: location

    Eine Änderung des Standorts eines Bildschirms (patchScreenLocation). Der Body hat kein anderes Mitglied.

  • ScreenMaintenanceAccepted — erforderlich: command_id, command, expires_at, state
  • ScreenManifestUpgrade — erforderlich: desired_revision, active_revision, desired_playlist, active_playlist, state, code, attempt, retry_at, missing_page_count, state_since, reported_at

    Immer vorhandener berechneter Manifest-Upgrade-Status für diesen Bildschirm, abgeleitet zur Lesezeit aus seiner ausgegebenen gewünschten Revision oder dem wartenden Ziel des geteilten Playlist-Inhalts, seiner letzten vom Server bestätigten aktiven Manifest-Revision (manifest.activated) und dem neuesten akzeptierten manifest.upgrade-Berichtslot.

    Nur lesender Projektstatus: kein Körper kann ihn schreiben, und kein Bericht fördert jemals eine Berechtigung. active_revision ist die zuletzt bestätigte Aktivierung, kein Beweis, dass jede gleichzeitige Sitzung sie bereits anzeigt.

    Offline-Sein führt nie zu einem Fehler, und ein überfälliges retry_at in einem Wiederholungszustand ist eine Clientanzeige, nie ein Serverurteil. desired_revision null bedeutet keine. Zustand pending benennt eine gewünschte Revision ohne passenden Bericht; activating benennt ein Ziel, das bereits auf dem Bildschirm ist und dessen Bestätigung noch aussteht; ein Berichtslot, dessen Revision nicht mehr mit desired_revision übereinstimmt, wird ignoriert, bis ein neuer Bericht passt, sodass ein neues gewünschtes Manifest pending wird, ohne etwas zu löschen.

    Bevor der nächste Manifestkontakt eine gewünschte Freigabe einer gemeinsamen Bearbeitung, die gewünschte Revision und Playlist meldet, kann dieses anstehende Ziel als schreibgeschützte Absicht angezeigt werden; es gewährt keinen Zugriff. Die aktive Identität stammt immer aus der exakt bestätigten historischen Freigabe. Eine ältere Aktivierung kann das neuere anstehende Ziel nicht als aktuell ankündigen.

  • ScreenMove — erforderlich: folder_id

    Mindestens eine ID in screen_ids und folder_ids zusammen, höchstens 1000 insgesamt.

  • ScreenMoveResult — erforderlich: screens, folders, levels
  • ScreenNamePatch — erforderlich: name

    Der neue Name eines Bildschirms (patchScreenName). Der Body hat kein weiteres Mitglied.

  • ScreenNotJudged — erforderlich: code, detail

    Etwas, das die Erklärung nicht beurteilt.

  • ScreenObservation — erforderlich: observed_at, surfaces

    Vom Player gemeldete Wiedergabefläche. Auf dem Bildschirm bis zum ersten akzeptierten PUT /screen/observation. nicht vorhanden. Schreibgeschützt in der Projekt-API; ScreenPatch, PairScreen, Pairing-Bodies, Session-Bodies, Leinwand, Laufzeitmanifest und POST /screen/reports können es nicht schreiben.

  • ScreenObservationSurface — erforderlich: id, width, height, pixel_ratio, presentation
  • ScreenOutage — erforderlich: offline_since

    Der jüngste Präsenzausfall des Bildschirms und, sobald der erste Zustandsbericht nach seiner Rückkehr es entscheidet, warum der Bildschirm weg war. Ein neuer Ausfall ersetzt ihn; ein Bildschirm, der seit der Erfassung von Ausfällen nie offline war, hat keinen.

    Die Ursache stammt aus den eigenen Laufzeitzählern des Players in diesem Bericht, gelesen gegen den Ausfall und nie gegen die Uhr des Geräts: device_restart (das Gerät startete nach Beginn des Ausfalls), app_crash (der Player startete und seine 24-Stunden-Absturzzahl stieg), app_restart (der Player startete, das Gerät nicht), network (keines startete, und nichts deutet auf screenRIG) und platform (keines startete, und ein player.stream_down-Bericht erreichte screenRIG während des Ausfalls, oder der Präsenzbeobachter war ausgefallen oder erholte sich, als der Bildschirm verstummte). likely_cause fehlt, wenn sie unbekannt ist, und bleibt lieber unbekannt, als zu raten: Ein Bericht ohne Laufzeiten, einer zu nah am Beginn des Ausfalls, ein Neustart nach der Rückkehr des Bildschirms und ein Player-Bericht innerhalb einer Minute nach der Wiederverbindung entscheiden nichts.

    Ein Bericht entscheidet nur innerhalb von 35 Minuten nach der Rückkehr des Bildschirms. device_restart kann Stromausfall und Neustart nicht unterscheiden, und network kann das eigene Netz des Bildschirms nicht von seinem vorgelagerten unterscheiden.

    Die Entscheidung hängt einmal das nur für das Projekt sichtbare Ereignis screen.outage_classified an, mit den Details {offline_since, back_at, likely_cause, evidence, online_event_id}; die Behebungsbenachrichtigung eines Offline-Bildschirms nennt die Ursache, wenn sie bis zum Versand der Meldung feststeht. Leser behandeln ein likely_cause, das sie nicht kennen, als unbekannt. Nur lesend; nie eine Autorisierung.

  • ScreenPatch — erforderlich: none
  • ScreenPlayPageAccepted — erforderlich: screen_id, playlist_id, page_id, manifest_revision, expires_at
  • ScreenPlayPageDetails — erforderlich: page_id, playlist_id, manifest_revision, expires_at

    Details-Objekt bei einem dauerhaften player.play_page-Ereignis.

  • ScreenPlayPageWrite — erforderlich: page_id
  • ScreenPlayerIdentity — erforderlich: legacy, seen_at

    Behauptete Identität aus dem zuletzt gekoppelten Laufzeit-Mint. Nur Anzeige-Metadaten, nie Autorisierung. Interne Grants und Mint-Felder werden zurückgehalten.

  • ScreenPlaylistPatch — erforderlich: playlist_id

    Eine Zuweisung der Playlist eines Bildschirms (patchScreenPlaylist). Der Body hat kein weiteres Mitglied.

  • ScreenPlaylistSchedule — erforderlich: entries, updated_at

    Serverbewerteter Playlist-Zeitplan. Er erreicht niemals das Laufzeitmanifest; das Manifest wird aus der effektiven Playlist erstellt, die er auswählt. Schreiben Sie ihn mit PUT /api/screens/{id}/playlist-schedule.

  • ScreenPlaylistScheduleView — erforderlich: entries
  • ScreenPlaylistScheduleWrite — erforderlich: entries
  • ScreenPresenceHistory — erforderlich: items, next_cursor
  • ScreenPresenceTransition — erforderlich: at, state
  • ScreenProvisioning — erforderlich: screen, public_url, provisioning_url, expires_at
  • ScreenRebootAccepted — erforderlich: reboot_id, expires_at, state
  • ScreenRebootSchedule — erforderlich: enabled, windows, updated_at

    Die Fenster, in denen das Backend den Bildschirm neu startet. Vorhanden, solange eines gesetzt ist.

  • ScreenRebootScheduleView — erforderlich: reboot_schedule, next_reboot_at
  • ScreenRebootScheduleWrite — erforderlich: enabled, windows
  • ScreenRecoveryHost — erforderlich: none

    Was das Gerät, das diesen Bildschirm wiederherstellen möchte, angibt, kopiert vom Host-Objekt des Kopplungsstarts. Nur beschreibende Felder; es enthält nie duid, Seriennummer oder mac. Fehlende Felder wurden nicht gemeldet.

  • ScreenRecoveryPending — erforderlich: expires_at

    Präsent, während eine native Pairing-Sitzung, die die Hardware-Identität dieses Bildschirms präsentierte, auf die Bestätigung des Besitzprojekts mit POST /api/screens/{id}/recovery/confirm. wartet. Trägt die Frist, die das eigene Ablaufdatum der Pairing-Sitzung ist, und die beschreibenden Hostfelder des anbietenden Geräts (niemals duid, Seriennummer oder mac).

    Eine DUID ist für jede Anwendung auf dem Panel lesbar, daher ist ein Angebot eine Phishing-Fläche: Vergleichen Sie host.model und host.firmware mit dem Display vor Ihnen, bevor Sie bestätigen.

    Der Server lehnt ein Angebot ab, während der gebundene Schlüssel des Bildschirms innerhalb der letzten zehn Minuten Leben gezeigt hat (Sitzungserstellung, Laufzeit-Stream, Manifest-Abruf oder Anwesenheits-Heartbeat) und akzeptiert höchstens drei Angebote pro Bildschirm pro rollender Stunde; ein neues Angebot ersetzt das ausstehende. Abwesend, sobald bestätigt, abgelaufen oder als neuer Bildschirm beansprucht. Nur lesen.

  • ScreenReloadAccepted — erforderlich: reload_id, expires_at, state
  • ScreenReplaceWrite — erforderlich: with
  • ScreenScheduleEntry — erforderlich: id, playlist_id
  • ScreenScheduleEntryWrite — erforderlich: playlist_id

    Ein Playlist-Planungseintrag, eine Ebene des eigenen Stacks des Bildschirms (packages/schedule-contract SEMANTICS.md, Levels and the stack). id ist optional (entry_N wird in Reihenfolge vergeben, wenn ausgelassen) und eindeutig im Zeitplan.

    Sie gilt, solange alle ihre Regelmitglieder gelten: from (einschließlich) und until (ausschließlich), zivile Grenzen mit Minutengenauigkeit ohne Offset; ein Vorkommen von windows, monthly oder dates (keines der drei: täglich), dessen Datum nicht in except steht; data, eine Card-Data-Bedingung; interaction, solange jemand den Bildschirm nutzt.

    Ein Eintrag setzt mindestens ein Regelmitglied. data, interaction, covers und eine displays-Sperre, die Ausgänge auslässt, werden von einem Player beachtet, der seinen eigenen Stack auflöst; die Auflösung des Servers für andere Player überspringt einen solchen Eintrag (stack_only).

  • ScreenSchedulePreviewRequest — erforderlich: entries
  • ScreenScheduleRevision — erforderlich: revision, created_at, change, current, entries

    Eine gespeicherte Revision des Playlist-Zeitplans eines Bildschirms: seine gesamte entries-Liste nach einem Schreibvorgang (keine entries: Der Bildschirm hatte keinen Zeitplan). revision ist die Revision des Bildschirms beim Schreibvorgang. change ist edited, restored (eine Kopie einer früheren Revision, benannt durch restored_from) oder baseline (der Zeitplan, den der Bildschirm zu Beginn seines Verlaufs hielt).

  • ScreenScheduleRevisionList — erforderlich: items
  • ScreenScheduleWindow — erforderlich: days

    Ein screenrig.schedule/v1-Zeitraum in der Zeitzone des Bildschirms. Tage sind von Mo bis So gespeichert. Start und Ende weglassen für den ganzen Tag. end <= start überschreitet Mitternacht und der Starttag besitzt ihn (Fr 22:00-02:00 läuft in den Samstagmorgen); gleiche Grenzen laufen 24 Stunden lang.

  • ScreenScope — erforderlich: folder_ids, screen_ids

    Worauf ein Mitglied oder Agent mit Bereich handeln darf (docs/screen-scope.md): die Bildschirme in den aufgeführten Bildschirmordnern und in jedem Ordner darin sowie die aufgeführten Bildschirme. Insgesamt mindestens eine ID. Eine ID, die beim Schreiben keinen aktiven Ordner oder Bildschirm des Projekts nennt, ist invalid_request an ihrer Position; eine spätere Löschung hinterlässt eine tote ID, die nichts gewährt.

    Der Bereich wird bei jeder Anfrage gelesen, sodass eine Änderung bei der nächsten gilt. Tags sind nie ein Bereich.

  • ScreenScreenshotAccepted — erforderlich: capture_id, expires_at
  • ScreenScreenshotFailedDetails — erforderlich: capture_id, reason

    Details-Objekt bei einem dauerhaften screen.screenshot_failed-Ereignis.

  • ScreenScreenshotReadyDetails — erforderlich: capture_id, bytes, width, height, sha256

    Details-Objekt bei einem dauerhaften screen.screenshot_ready-Ereignis. Pixel und Objekt-Schlüssel sind nicht vorhanden.

  • ScreenScreenshotRequestedDetails — erforderlich: capture_id, expires_at, max_width_divisor, max_height_divisor, format, quality, max_bytes

    Details-Objekt bei einem dauerhaften screen.screenshot_requested-Ereignis. Bildbytes und Objekt-Schlüssel sind nicht vorhanden.

  • ScreenScreenshotStatus — erforderlich: state
  • ScreenStackStatus — erforderlich: manifest_revision, levels, playing, reported_at

    Was der Player des Bildschirms zuletzt von seinem Stack gemeldet hat (docs/player-compatibility.md §6.11): die Bereitschaft jeder Ebene und die Ebene, die jedes Display in jeder Region zeigt (die Seite und jeder Streifen). Nur vorhanden bei einem Player, der seinen eigenen Stack auflöst, solange dieser Stack aktuell ist.

  • ScreenStatus — erforderlich: chip, observed_at, received_at

    Der Status-Chip, den der Player des Bildschirms zuletzt mit PUT /screen/status gemeldet hat (docs/player-compatibility.md §9.5): die Bedingung aus screenrig.overlay/v1, die ihren Rang gewinnt, oder null, wenn der Player keinen Chip zeigt. Fehlt bis zum ersten akzeptierten Bericht. Wird bei Identitäts-Reset, Entpaarung und Archivierung gelöscht.

    Es ist der letzte Bericht des Players, daher behandeln Verbraucher ihn als veraltet, wenn der Bildschirm nicht online ist (Screen.online), wie jeden Player-Bericht. level und icon stammen aus dem Katalog des Backends für chip, nie vom Player, und fehlen, wenn chip null ist. Nur lesbar über die Projekt-API. Niemals Autorisierung oder Zulassung. ScreenPatch kann es nicht schreiben.

  • ScreenStatusChangedDetails — erforderlich: chip

    Details-Objekt bei einem dauerhaften, nur für das Projekt gültigen Ereignis screen.status_changed, das angehängt wird, wenn PUT /screen/status den gespeicherten chip, level oder icon ändert. level und icon fehlen, wenn chip null ist. Dieser Typ ist kein Laufzeit-Audience-Befehl und wird nicht bei GET /screen/events geliefert.

  • ScreenStorage — erforderlich: observed_at, received_at, volume, cache, durability, plan, transfer_24h

    Bereinigter Player-Speicherbericht. Fehlend bis zum ersten akzeptierten PUT /screen/storage. Wird bei Identitäts-Reset, Entpaarung und Archivierung gelöscht. Verbraucher behandeln received_at, das älter als 24 Stunden ist, als veraltet. Nur lesbar über die Projekt-API. Niemals Autorisierung oder Zulassung. ScreenPatch kann es nicht schreiben.

  • ScreenStorageCache — erforderlich: house_used_bytes, capacity_bytes, reserve_bytes, protected_bytes, fallback_bytes, warm_bytes, ad_headroom_bytes
  • ScreenStorageExcludedPage — erforderlich: page_id, reason
  • ScreenStorageForecast — erforderlich: manifest_revision, fit, excluded_page_count, basis, received_at

    Ungefähre Zielauswahl im stationären Zustand (nur Plan A.3, kein Übergang) aus der zuletzt gemeldeten Kapazität und dem gewünschten Manifest des Bildschirms. Fehlt ohne Speicherbericht, den Verbraucher als unbekannt lesen. Basis ist reported_capacity. Wird neu berechnet, wenn ein Speicherbericht eintrifft und wenn sich die Manifestrevision des Bildschirms ändert. Nie Autorisierung oder Zulassung.

  • ScreenStorageForecastDryRun — erforderlich: fit, excluded_page_count, required_bytes, capacity_bytes, basis, received_at

    Vorab-Fit-Trockenlauf für eine Playlist. fit, excluded_page_count und required_bytes stammen aus Plan A.3 Zielauswahl basierend auf der zuletzt gemeldeten Kapazität des Bildschirms (Basis reported_capacity); es gibt keine Übergangsvorhersage und nichts wird als lokal behandelt. required_bytes ist die gehaltene Kostenmenge jeder Seite der Playlist. Unbekanntes fit bedeutet, dass der Bildschirm keinen Speicherbericht hat oder die Inhaltsreferenzen der Playlist nicht bereit sind; required_bytes, capacity_bytes und received_at sind dann null. received_at ist die Empfangszeit des Speicherberichts, und ein älterer Bericht als 24 Stunden ist veraltet, wird aber weiterhin prognostiziert, genau wie Screen.storage_forecast.

    Sie ist nur Metadaten und niemals Autorisierung oder Zulassung.

  • ScreenStorageForecastRequest — erforderlich: playlist_id

    Body des Fit-Trockenlaufs vor der Zuweisung. playlist_id muss eine Playlist des authentifizierten Projekts sein; ein anderes Projekt oder eine unbekannte ID ist not_found.

  • ScreenStoragePlan — erforderlich: manifest_revision, fit, transition, required_bytes, target_bytes, excluded_pages
  • ScreenStorageShortfall — erforderlich: at, fit, required_bytes, capacity_bytes, excluded_page_count

    Vorhanden, während die gemeldete Passform des Players teilweise, transition_blocked oder none_fit ist, außer bei einem transition_blocked-Plan, dessen einziger Blockierungsgrund anchor_unavailable ist: Das ist ein fehlgeschlagener Download auf einem Gerät mit Platz, kein Mangel. at ist der Zeitpunkt, an dem die Bedingung begann.

    Es wird einmal gesetzt, wenn die Bedingung beginnt, und entfernt, wenn sie endet, wobei jeder Übergang ein projektbezogenes Ereignis anhängt, screen.storage_shortfall oder screen.storage_shortfall_cleared. Diese Ereignisse werden bei GET /screen/events. nicht geliefert. Werden bei Identitätszurücksetzung, Entpaarung und Archivierung mit Screen.storage gelöscht.

    Nur lesende Projekt-Gesundheitsmetadaten; ändert nicht die Bildschirmrevision oder Manifestbefugnis und ist niemals Autorisierung.

  • ScreenStorageTransfer — erforderlich: new, refetch, repair, failed
  • ScreenStorageVolume — erforderlich: total_bytes, available_bytes
  • ScreenSurfaceChangedDetails — erforderlich: observed_at, surfaces

    Details-Objekt bei einem dauerhaften screen.surface_changed Projekt-Ereignis. Pixel sind nicht vorhanden. Dieser Typ ist kein Laufzeit-Audience-Befehl und wird bei GET /screen/events. nicht geliefert.

  • ScreenSuspendWrite — erforderlich: message
  • ScreenSuspension — erforderlich: message, since

    Vorhanden, solange der Bildschirm ausgesetzt ist (docs/player-compatibility.md §6.9). Das Laufzeit-Manifest enthält dasselbe Objekt als sein suspension-Mitglied.

  • ScreenTags — erforderlich: none

    Flotten-Selektortags, 0 bis 16 eindeutige exakte Tags, die jeweils der Medien-Tag-Grammatik entsprechen. Bei ScreenPatch ersetzt das Array das gesamte Set, und ein leeres Array löscht es; ein doppeltes oder fehlerhaftes Tag ist invalid_request. Das Ändern der Tags erhöht die Bildschirmrevision (If-Match schützt sie) und fügt screen.updated mit details.tags hinzu; die Manifestrevision ändert sich nie.

    Tags sind niemals im Laufzeitmanifest und niemals in der Autorisierung enthalten.

  • ScreenTagsPatch — erforderlich: tags

    Ein vollständiger neuer Tag-Satz eines Bildschirms (patchScreenTags). Das Array ersetzt alle Tags, die der Bildschirm trägt, und ein leeres Array löscht sie. Der Body hat keine weiteren Mitglieder.

  • ScreenTakeover — erforderlich: playlist_id, until, set_at

    Die Playlist, die bis until Vorrang vor Kampagnen, Zeitplan und Zuweisung hat, oder bis zur Aufhebung, wenn until null ist.

  • ScreenTakeoverWrite — erforderlich: playlist_id
  • ScreenTimelineSegment — erforderlich: from, to, source
  • ScreenToastAccepted — erforderlich: expires_at
  • ScreenToastDetails — erforderlich: level, text, duration_ms, expires_at

    Details-Objekt bei einem dauerhaften screen.toast-Ereignis. Farben sind nicht vorhanden.

  • ScreenToastWrite — erforderlich: level, text
  • ScreenUptime — erforderlich: items
  • ScreenVerbosityPatch — erforderlich: none

    Eine Änderung der Log-Stufe und der Toast-Stufe eines Bildschirms (patchScreenVerbosity). Der Body nennt mindestens eines der beiden Mitglieder und kein anderes.

  • ScreenVerdict — erforderlich: kind, playlist_id, verdict

    Ein Kandidat zum erklärten Zeitpunkt. won: Der Resolver wählt ihn (auf einem Bildschirm, dessen Player seinen eigenen Stapel auflöst: Er füllt seine Region auf einem adressierten Display). outranked: Er gilt, und by ist der Kandidat, der gewonnen hat. not_started: vor seinem from. ended: ab seinem until oder danach (eine Übernahme: ihr Ende). outside_hours: zwischen from und until, außerhalb seiner Fenster. conditional: Auf einem Bildschirm, dessen Player seinen eigenen Stapel auflöst, gilt er zeitlich und spielt, solange auch die nur vom Player beobachtete Bedingung erfüllt ist (reason interaction oder data). off: Er gilt nicht, und reason nennt den Grund.

  • ScreenWall — erforderlich: outputs, arrangement

    Die Videowand, die ein Player eines Bildschirms anordnet: zwei bis zwölf Ausgänge, die eine Leinwand zeigen. Die Einstellung erfordert einen Player, der die display.wall-Host-Fähigkeit deklariert hat (docs/player-compatibility.md §6.5, §6.8). Eine Playlist mit einem Format erstreckt sich darüber.

  • ScreenshotCaptureID — erforderlich: none

    Optionales Präfix stage_, qa_ oder development_, dann shot_ und ein zufälliger Suffix. Neue Suffixe verwenden 16 alphanumerische Zeichen ohne oOlL; beibehaltene Legacy-Suffixe werden akzeptiert.

  • SelectorPreview — erforderlich: primitive, selector, matched_count, candidates
  • SelectorPreviewInput — erforderlich: primitive, selector
  • SelectorPreviewMedia — erforderlich: media_id, filename, tags
  • ServiceClient — erforderlich: id, project_id, name, capabilities, access, state, created_by, keys, secrets, created_at, updated_at, authenticated_requests, tokens_issued
  • ServiceClientChange — erforderlich: none
  • ServiceClientKey — erforderlich: kid, alg, thumbprint, jwk, added_at
  • ServiceClientList — erforderlich: items
  • ServiceClientResult — erforderlich: client
  • ServiceClientSecret — erforderlich: id, hint, added_at
  • SessionDescription — erforderlich: type, sdp
  • SessionSSOStartRequest — erforderlich: intent
  • SignInPolicy — erforderlich: password, passkey, passkey_enrollment_required, policy_revision, federated

    Verifizierte Anmelderichtlinie für Personen. Passive Standardwerte erhalten die lokale Anmeldung. Eine durchgesetzte Organisationsrichtlinie leitet die Anmeldung über deren Identitätsanbieter.

  • SignInResetAccepted — erforderlich: status

    Identisch für bekannte und unbekannte Adressen; keine Adresse, Anmeldeinformationen, Projekt- oder Lieferstatus wird zurückgegeben.

  • SignInResetRequest — erforderlich: email
  • SignupCreated — erforderlich: user_id, project_id, organization_id
  • SignupHeardDetail — erforderlich: none

    Die Nachfrage zu heard. kind nennt eine Auswahl aus einer kurzen Liste, und text ist Freitext.

  • SignupPasskeyOptionsRequest — erforderlich: email, display_name
  • SignupProfile — erforderlich: none

    Die Antworten, die eine Person nach der Registrierung gibt. Jedes Mitglied ist optional und kann null sein, was unbeantwortet oder übersprungen bedeutet.

  • SignupRequest — erforderlich: email, display_name, marketing_email, credential

    E-Mail-Adresse und Anzeigename sind die, mit denen die Zeremonie gestartet wurde.

  • Source — erforderlich: id, name, kind, target, enabled, config, preset, settings, secrets, refresh_seconds, stale_after_seconds, revision, status, created_at, updated_at
  • SourceArea — erforderlich: key, name, rooms, status, screens
  • SourceCreate — erforderlich: name, target

    Die Konfiguration von JSON, CSV und Sheets kann key_template festlegen, einen Kartendatenschlüssel mit {screen.field.NAME}-Tokens. Die Zuordnung erzeugt dann {documents:[{fields:{NAME:VALUE},document:{...}}]} statt eines einzelnen Dokuments. Jede Ausgabe wird anhand der Zielkarte validiert.

    Schlüssel sind eindeutig und liegen außerhalb der Namensräume für Karteninstanzen und Feeds; source test zeigt eine Vorschau des Umschlags und validiert jede Ausgabe. Jeder Schlüssel verwendet die Veraltungsfrist der Quelle. Fehlende Schlüssel behalten ihre Daten und Ablaufzeit; Speicherfehler können zu Teilschreibvorgängen führen, die beim nächsten Lauf wiederholt werden.

  • SourceError — erforderlich: code, message, at
  • SourceKind — erforderlich: none

    Woher die Daten kommen. ics liest iCalendar- und webcal://-Adressen (die anderen Arten sind unter /docs/sources beschrieben). Eine Art, die nicht verfügbar ist, antwortet mit invalid_request bei kind.

  • SourceList — erforderlich: items, next_cursor
  • SourcePreset — erforderlich: name, title, category, description, kind, cards, fields, secrets, refresh_seconds, min_refresh_seconds, stale_after_seconds, attribution, docs

    Eine fertige, getestete Konfiguration der json-Datenquelle.

  • SourcePresetAttribution — erforderlich: text
  • SourcePresetCard — erforderlich: type, default
  • SourcePresetField — erforderlich: name, label, type, required, help

    Eine Angabe, die eine Person einer Voreinstellung macht. Ein Text wird gegen pattern und max_length geprüft, eine Auswahl ist eine von options, und eine Liste enthält min_items bis max_items Objekte, die mit fields ausgefüllt werden.

  • SourcePresetList — erforderlich: items
  • SourcePresetOption — erforderlich: value, label
  • SourcePresetSecret — erforderlich: name, label, help, how_to_get, required

    Eine Zugangsberechtigung, die eine Voreinstellung braucht, unter name in secrets eingetragen.

  • SourceRoom — erforderlich: key, status, screens
  • SourceRoomRef — erforderlich: id, name
  • SourceRoomScreen — erforderlich: id, name, kind, field, value, status
  • SourceRooms — erforderlich: source_id, room_field, room_key_prefix, area_field, area_key_prefix, rooms_as_of, summary, rooms, areas, screens, warnings

    Die Raumzuordnung einer Datenquelle, die für jeden Raum oder Bereich ein Dokument schreibt: die Räume, die die Quelle bei ihrer letzten guten Aktualisierung anbot, gegenüber den Bildschirmen, die sie lesen.

    Ein Bildschirm gehört zum Bericht für ein Feld, wenn er dafür einen Wert hat oder wenn seine eigene Playlist eine Card platziert, deren Datenschlüssel das Schlüsselpräfix gefolgt von {screen.field.NAME} ist; eine Playlist, die über einen Ordner, eine Kampagne oder eine Zeitplanebene erreicht wird, wird nicht verfolgt.

  • SourceRoomsSummary — erforderlich: rooms, unmapped_rooms, areas, unmapped_areas, screens, missing_screens, unknown_screens
  • SourceSecretView — erforderlich: set, hint, updated_at
  • SourceStaleAfter — erforderlich: none

    Wie lange die Card die letzten guten Daten der Quelle behält, wenn sie nicht aktualisieren kann, in Sekunden.

    Die Quelle schreibt ihre Dokumente so, dass sie so lange nach der letzten guten Aktualisierung ablaufen: Fällt sie weiter aus, werden sie auf jedem Bildschirm leer (auch auf Offline-Bildschirmen), und Seiten, deren Sichtbarkeit von den Daten abhängt, fallen auf die folgenden Seiten zurück; eine Quelle, die nicht ausfällt, erneuert die Frist bei jeder Aktualisierung.

    Mindestens das Doppelte von refresh_seconds. null behält die letzten guten Daten, bis die Quelle wieder aktualisiert (der Standard jeder Art außer momentus, deren Standard 1800 ist, wenn das Member beim Anlegen fehlt). Eine fehlerhafte Quelle, die den Zeitraum überschreitet, ist veraltet (status.stale) und hängt source.stale an.

  • SourceStatus — erforderlich: state, last_attempt_at, last_success_at, last_change_at, next_run_at, failures, stale, data_expires_at, error, warnings, stats

    Was die letzten Läufe getan haben. state ist pending (noch nicht gelaufen), ok (der letzte Abruf war erfolgreich und die Karte hat das Dokument akzeptiert), error (der letzte Lauf ist fehlgeschlagen und die Karte hat ihr letztes gutes Dokument behalten) oder disabled. ok beurteilt nicht, ob die Daten der Quelle richtig oder aktuell sind oder ob ein Bildschirm die Karte zeigt.

  • SourceTarget — erforderlich: card_id
  • SourceTestRequest — erforderlich: none
  • SourceTestResult — erforderlich: document, valid, warnings, stats, fetched_at
  • SourceUpdate — erforderlich: none
  • StackLevel — erforderlich: id, source, playlist_id

    Eine Ebene des Stacks eines Bildschirms (packages/schedule-contract SEMANTICS.md, Levels and the stack). id ist takeover, campaign:ID, schedule:ENTRY_ID, default oder folder:FOLDER_ID; record_id nennt die Kampagne, den Eintrag oder den Ordner, name den Namen der Kampagne oder des Ordners. Fehlt rule, gilt die Ebene immer.

  • StackLevelRule — erforderlich: none
  • StreamSource — erforderlich: none
  • StreamSourceWrite — erforderlich: none

    Eine Stream-Quelle. Eine Quelle kann nur ihre url angeben und das Schema das Protokoll bestimmen lassen: https ist hls, rtsp und rtsps sind rtsp.

  • SupportConversation — erforderlich: id, subject, created_at, updated_at, last_sequence, human_requested, unread_staff, closed
  • SupportConversationList — erforderlich: items, next, unread_staff_total
  • SupportHours — erforderlich: timezone, start, end, weekdays, excludes_bc_holidays
  • SupportMessage — erforderlich: id, conversation_id, sequence, role, author, body, created_at
  • SupportMessageList — erforderlich: items
  • SupportRead — erforderlich: sequence
  • SupportStatus — erforderlich: chat_allowed, available, staffed, human_available, hours, human_wait_seconds, docs_url
  • SupportSubmission — erforderlich: conversation, message
  • SupportWrite — erforderlich: body
  • TabShare — erforderlich: id, until, screens, skipped, warnings
  • TabShareCookie — erforderlich: name, value, domain

    Ein Cookie im Format der Cookie-API des Browsers. Der Wert ist geheim.

  • TabShareScreen — erforderlich: id, label
  • TabShareSkip — erforderlich: id, label, code, detail

    Ein nicht übernommenes Ziel. code ist der Problemcode, den die einzelne Übernahme dieses Bildschirms liefern würde.

  • TabShareState — erforderlich: id, until, screens
  • TabShareStopped — erforderlich: id, screens
  • TabShareWarning — erforderlich: code, url, detail
  • TabShareWrite — erforderlich: tabs

    Die anzuzeigenden Tabs und ihre Zielbildschirme. Mindestens eines von screen_ids, folder_ids und tags.

  • Trigger — erforderlich: id, kind, label, target, default_for_seconds, url, username, revision, created_at, updated_at

    Ein CAP-Alarm-Trigger oder ein Overlay-Trigger. Sein Passwort liefern nur create und rotate-secret zurück.

  • TriggerAlert — erforderlich: id, revision, state, status, msg_type, sender, identifier, until, screens, started_at, updated_at

    Der neueste Alarm des Triggers, aus den CAP-Nachrichtenfeldern.

  • TriggerAlertScreens — erforderlich: targeted, taken_over, cleared, skipped, failed, pending

    Was die letzte Übernahmeänderung bewirkt hat. Übersprungen werden Bildschirme ohne Standard-Playlist, archivierte oder verschwundene, und beim Löschen Bildschirme, die seitdem von einer anderen Übernahme ersetzt wurden.

    Ein Bildschirm in einem geschützten Bildschirmordner bleibt, wie er ist, und wird in protected gezählt, nicht übersprungen; das Beenden eines Alarms (Abbrechen, Entwarnung, eine Betreiber-Aufhebung) hebt weiterhin auf, was der Trigger auf einem solchen Bildschirm gesetzt hat.

  • TriggerClear — erforderlich: none
  • TriggerDelivery — erforderlich: at, outcome, status, bytes, request_id
  • TriggerDeliveryList — erforderlich: items
  • TriggerList — erforderlich: items
  • TriggerOverlay — erforderlich: show, style, enabled, signing, alerts, screens, pending

    Konfiguration und Zustand eines Overlay-Triggers.

  • TriggerOverlayAlert — erforderlich: id, until, started_at, updated_at, revision
  • TriggerOverlayReceipt — erforderlich: outcome, trigger_id, until, active
  • TriggerOverlayRequest — erforderlich: none

    Eine Sendung an einen Overlay-Trigger, so gelesen, wie sie nach dem mapping des Triggers (falls vorhanden) vorliegt. Ein Beenden ignoriert jedes Feld außer alert_id, clear und state.

  • TriggerOverlayScreens — erforderlich: targeted, holding, taken_over, removed, edge_taken, skipped, failed

    Was die letzte Verteilung mit den Zielbildschirmen gemacht hat. Ein Bildschirm in einem geschützten Bildschirmordner bleibt, wie er ist, und wird in protected gezählt, nicht übersprungen; das Beenden des Alarms hebt weiterhin auf, was der Trigger dort gesetzt hat.

  • TriggerOverlayStyle — erforderlich: none

    Die statischen Parameter der Textkarte, mit denen ein Overlay gezeichnet wird. Der Trigger wählt das Layout.

  • TriggerOverlayWrite — erforderlich: show
  • TriggerPatch — erforderlich: none
  • TriggerReceipt — erforderlich: outcome, trigger_id
  • TriggerSecretRotate — erforderlich: none
  • TriggerTarget — erforderlich: none

    Genau eines von tag und screen_ids.

  • TriggerWithPassword — erforderlich: none
  • TriggerWithSecrets — erforderlich: none
  • TriggerWrite — erforderlich: label, target
  • UDPStreamSource — erforderlich: protocol, group, port
  • URLStreamSource — erforderlich: url
  • UploadScope — erforderlich: playlist_ids, folder_ids

    Was ein Uploader verwenden darf (docs/uploaders.md): die Playlists, deren Seiten er ändert, und die Medienordner, in die er hochlädt. Ordner sind genau die aufgelisteten, nie deren Unterordner. Eine ID, die beim Schreiben kein aktives Objekt des Projekts benennt, ergibt invalid_request an ihrer Position; ein späteres Löschen hinterlässt eine tote ID, die nichts gewährt.

    Der Bereich wird bei jeder Anfrage gelesen, sodass eine Änderung ab der nächsten gilt.

  • UptimeDay — erforderlich: day, online_s, offline_s, availability, coverage

    Ein UTC-Tag. Verfügbarkeit ist online_s geteilt durch online_s plus offline_s, null wenn nichts aufgezeichnet wurde. Abdeckung ist der Anteil des Tages (von jedem Berichtstag eines Bildschirms in einer Projektzeile) mit einem aufgezeichneten Zustand, 0 bis 1: eine Lücke verringert die Abdeckung und ist niemals Offline-Zeit. Intervalle (Bildschirmzeilen) sind die Anzahl der aufgezeichneten Intervalle, die den Tag berührten; Bildschirme (Projektzeilen) sind die Anzahl der Bildschirme mit aufgezeichnetem Zustand; live markiert einen Bildschirmtag, der das offene Intervall bis jetzt einschließt.

  • UsageFrame — erforderlich: page_id, primitive_id, rect

    Ein Bild- oder Video-Primitiv, das die Mediendatei benennt, mit seinem Rahmen und der Art, wie die Datei ihn ausfüllt.

  • UsageScreen — erforderlich: id, label, screen, playlist_ids, how

    Ein aktiver Bildschirm, der mindestens eine der aufgelisteten Playlists verwendet.

  • UsageScreenHow — erforderlich: playlist_id, uses
  • UsageTagFilter — erforderlich: all, any, none

    Der Filter eines Tag-Selektors. Eine Datei passt, wenn sie alle Tags aus all hat, mindestens eines der Tags aus any (sofern any Tags nennt) und keines der Tags aus none; der Kurzform-Tag-Selektor ist all mit einem Tag.

  • UsageTrack — erforderlich: index, id
  • UserEmailChangeAccepted — erforderlich: none
  • UserEmailChangeRequest — erforderlich: email, proof

    Fordert eine Änderung der verifizierten E-Mail mit frischem Nachweis an. Die aktuelle E-Mail bleibt wirksam, solange die Verifizierung aussteht. Die alte Adresse erhält nur eine Warnung, keinen Rückgängig-Link.

  • VerifiedOrganizationDomain — erforderlich: domain, organization_id, state, verified_at
  • VersionResponse — erforderlich: version, commit, api_version, protocol_version
  • Webhook — erforderlich: id, url, event_types, enabled, revision, status, created_at, updated_at

    Ein Projekt-Webhook. Player-Log-Einträge (runtime.reported) werden nicht geliefert.

    Jedes passende Projekt-Ereignis wird als dasselbe JSON-Objekt, das GET /api/events zurückgibt, an die URL per POST gesendet, mit den Headern ScreenRig-Webhook-Id, ScreenRig-Event-Id (der Ereignis-Cursor, stabil bei Wiederholungen), User-Agent und ScreenRig-Signature t=<unix seconds>,v1=<hex HMAC-SHA256 over "<t>.<raw body>" mit dem geheimen String als Schlüssel>.

    Eine 2xx-Antwort innerhalb von 10 Sekunden gilt als erfolgreich; jeder andere Status, eine Weiterleitung (niemals gefolgt), ein Timeout oder eine Verbindungs- oder TLS-Fehlfunktion wird mit exponentiellem Backoff (30 Sekunden, verdoppelt bis zu einer Stunde, mit Jitter) für 24 Stunden erneut versucht und dann als fehlgeschlagen gewertet. Nach drei aufeinanderfolgenden Timeouts sinkt das Timeout auf 5 Sekunden, bis eine Antwort eintrifft.

    Ein Webhook hat höchstens einen Versuch in Bearbeitung und ein Projekt höchstens zwei, über alle Server hinweg. Die Zustellung erfolgt mindestens einmal und ungeordnet; deduplizieren Sie anhand von ScreenRig-Event-Id.

    Jeder Versuch wird wie ein Listen-Stream-Ereignis abgerechnet (1 Credit nach dem monatlichen API-/SSE-Kontingent von 10.000), und dieselben Ereignisse, die im Listen-Stream kostenlos sind, sind auch hier kostenlos: screen.*, runtime.*, alert_mute.*, application.event, playback.page_failed und agent.command.

    Ein Versuch, der abgelehnt wird, bevor etwas gesendet wird (url_rejected, dns_failed), wird nicht berechnet. payment_required und secret_unavailable führen zu einem Backoff, zählen aber nie für failing oder die automatische Deaktivierung. status ist failing, solange seit failing_since keine Zustellung erfolgreich war; nach 72 Stunden ununterbrochener Fehler wird der Webhook deaktiviert (disabled_reason delivery_failures) und notification.disabled wird angehängt.

  • WebhookDelivery — erforderlich: id, webhook_id, event_id, event_type, state, attempts, created_at
  • WebhookDeliveryAttempt — erforderlich: attempt, at, status, error, duration_ms
  • WebhookDeliveryAttemptList — erforderlich: items
  • WebhookDeliveryList — erforderlich: items, next_cursor
  • WebhookEventTypes — erforderlich: none

    Exakte Ereignistypen wie screen.online oder Präfixe, die auf .* enden, wie screen.* (jeder Typ, der mit screen. beginnt). notification.test wird nie über ein Abonnement verteilt; es wird nur von POST /api/webhooks/{id}/test gesendet.

  • WebhookHandshake — erforderlich: none

    Ein Anbieter-Handshake, den die URL beantwortet, für einen Anbieter ohne Signaturschema hier. microsoft_graph beantwortet einen POST mit dem Abfrageparameter validationToken, indem es das decodierte Token als text/plain zurückgibt. monday beantwortet einen JSON-POST von {"challenge": "..."} mit demselben JSON. trello beantwortet seine HEAD-Prüfung mit 200. azure_event_grid beantwortet ein SubscriptionValidationEvent (aeg-event-type: SubscriptionValidation) mit {"validationResponse": "<validationCode>"}. verify.vendor slack beantwortet die signierte url_verification-Challenge von Slack, und verify.vendor asana beantwortet den X-Hook-Secret-Handshake von Asana und behält dieses Secret, um seine Ereignisse zu prüfen.

    Ein Handshake wird nur für einen Webhook beantwortet, der für diesen Anbieter eingerichtet ist, schreibt nichts, wird nie abgerechnet und verbraucht kein Ratenbudget und wird im Zustellprotokoll mit dem Ergebnis handshake festgehalten. Ein deaktivierter Webhook beantwortet keinen.

  • WebhookList — erforderlich: items
  • WebhookPatch — erforderlich: none
  • WebhookVerify — erforderlich: vendor, secret

    Die Anbieterprüfung eines Webhooks oder Triggers, wie sie ein Lesezugriff zeigt. Das Secret ist immer nur ein Hinweis.

  • WebhookVerifyVendor — erforderlich: none
  • WebhookVerifyWrite — erforderlich: vendor

    Ein Anbieter, dessen eigene Signatur eine Zustellung anstelle des Secrets authentifiziert, weil diese Anbieter unseres nicht senden können.

    Header und Schema sind jeweils die des Anbieters und fest: github sendet X-Hub-Signature-256, sha256= und das hexadezimale HMAC-SHA256 des Body; stripe sendet Stripe-Signature, t=<unix seconds>,v1=<hex HMAC-SHA256 of "<t>.<body>"> (mehrere v1, während ein Secret rotiert wird, t innerhalb von fünf Minuten); shopify sendet X-Shopify-Hmac-Sha256, das Base64-HMAC-SHA256 des Body; slack sendet X-Slack-Signature, v0= und das hexadezimale HMAC-SHA256 von "v0:<X-Slack-Request-Timestamp>:<body>" (innerhalb von fünf Minuten); linear sendet Linear-Signature, das hexadezimale HMAC-SHA256 des Body, und das Mitglied webhookTimestamp des Body (Unix-Millisekunden) muss innerhalb einer Minute liegen; vercel sendet x-vercel-signature, das hexadezimale HMAC-SHA1 des Body; asana sendet X-Hook-Signature, das hexadezimale HMAC-SHA256 des Body, mit dem X-Hook-Secret aus dem Handshake von Asana als Schlüssel; generic_hmac ist jeder Sender, der im von Ihnen benannten Header mit HMAC-SHA256 signiert.

    Eine Zustellung mit gültiger Signatur wird ohne das Secret akzeptiert, und das Secret funktioniert daneben weiter. verify lässt sich nicht mit signing kombinieren. Eine Zustellung wird am Body so beurteilt, wie er ankam, bevor sie Ratenbudget verbraucht. Slack und Asana beantworten auch ihre Handshakes (siehe WebhookHandshake).

  • WebhookWithSecret — erforderlich: id, url, event_types, enabled, revision, status, created_at, updated_at, secret

    Ein Webhook plus dessen Signatur-Geheimnis. Wird nur bei Erstellung und Geheimnisrotation zurückgegeben.

  • WebhookWrite — erforderlich: url, event_types
  • WebsiteSetupCode — erforderlich: code, expires_at