Stripchat Extension Platform

Appearance

Monitoring ​

Extensions can send monitoring signals to the platform from inside the iframe. This is useful when you want to report unexpected errors or add a small amount of structured diagnostic logging from the extension runtime.

Use monitoring requests through makeRequest:

Internal monitoring only

These monitoring signals are collected for the Stripchat platform and review teams. Extension developers do not get direct access to these reported errors and logs from the platform side.

Platform monitoring vs your own monitoring ​

The platform monitoring requests described on this page are only one option.

It is also completely fine to use your own monitoring system inside the extension iframe, for example:

  • Sentry
  • your own backend endpoint via Backend Actions
  • your own backend endpoint via a direct request from the iframe
  • your own error tracking or observability pipeline

If you send monitoring data through Backend Actions, the request is performed server-side by the platform.

If you send monitoring data directly from the iframe to your own backend, make sure the required external domains are added to your extension Restrictions during version creation/upload. Those Restrictions generate the extension CSP, and without the appropriate CSP your requests may be blocked inside the iframe.

See Upload Extension for the Restrictions step, and How do Extensions Work? for the CSP overview.

Why use it ​

Monitoring is not mandatory for publishing an extension, and your extension should not depend on it for core functionality.

At the same time, it is a good practice to report important errors and a small number of meaningful logs:

  • it helps the Stripchat platform and review teams notice important extension failures;
  • it helps the Stripchat platform team investigate integration issues faster;
  • it gives the Stripchat team more context when debugging extension-specific problems in the future.

Think about it as a good operational hygiene for production extensions, not as a hard requirement.

Recommended, not required

If your extension works without platform monitoring, that is completely fine. But if you report a few high-value failures and lifecycle events, it gives the Stripchat team better context during review and incident investigation. If your own team needs direct visibility, use your own monitoring system as well.

When to report error ​

Use v1.monitoring.report.error for situations where something went wrong and the extension cannot continue normally, or is forced into degraded behavior.

Typical examples:

  • initialization failed;
  • required data has invalid shape;
  • your extension received an unexpected backend response;
  • a critical user flow cannot continue.

Keep the message short and stable. Put changing details into data.

Prefer stable messages such as extension bootstrap failed or config action request failed, and put runtime-specific details such as stage, action name, status code, or serialized error data into data.

When to report log ​

Use v1.monitoring.report.log for important operational events that help explain extension behavior, but are not errors by themselves.

Good examples:

  • extension started with fallback mode enabled;
  • backend feature was disabled by configuration;
  • an external integration became temporarily unavailable and the extension switched to a safe mode;
  • you want to mark a meaningful lifecycle event during rollout.

Avoid sending noisy logs for every render, click, timer tick, or animation frame.

For logs, use short event-oriented messages such as fallback mode enabled and keep the variable context inside data, for example the bootstrap stage, fallback reason, or current slot.

Best practices ​

  • Use a stable message value that is easy to search and aggregate.
  • Put variable details in data as a structured JSON-serializable object.
  • Report only meaningful signals. Too many low-value logs make real problems harder to find.
  • Do not send secrets, access tokens, or other sensitive user data.
  • Do not use monitoring requests as part of business logic. They should remain observational only.
  • Do not treat monitoring requests as a developer-facing log console. They are intended for Stripchat platform-side investigation and operational support.
  • If you use Sentry or any other external monitoring service, remember to whitelist its domains in your extension Restrictions/CSP.

Suggested pattern ​

In practice, a good baseline is:

  • report error for failures that break initialization, block a main flow, or force a degraded state;
  • report log for important lifecycle milestones and fallback decisions;
  • keep regular debugging output in local development tools such as the browser console.

This keeps platform monitoring focused on high-value operational signals, while direct developer debugging stays in your own monitoring stack or local browser tools.