> ## Documentation Index
> Fetch the complete documentation index at: https://docs.mixpeek.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.
# Using Mixpeek on corporate networks
> If Mixpeek won't load behind a corporate proxy or firewall, allowlist these domains — a one-page checklist for IT administrators
If Mixpeek Studio loads a blank page, hangs on sign-in, or "goes dead" a few
seconds after opening on your corporate network, the cause is almost always a
**proxy, firewall, or content-security policy blocking outbound requests** the app
needs to make. Mixpeek's own security policy already permits every domain below —
the block is on the network side, so the fix is a network-side allowlist.
This page is written for an IT administrator to action in one read.
**The symptom:** the browser loads `studio.mixpeek.com`, but calls to the API are
silently dropped, so the app renders its shell and then does nothing — no data, no
sign-in, no error. That is a blocked `api.mixpeek.com`, not a Mixpeek outage.
## Minimum allowlist — the app loads and works
Allowlist these for **outbound HTTPS (443)** from the browser. This is the smallest
set that makes Studio and the API fully functional:
| Domain | Purpose |
| ------------------------------- | ------------------------------------------------------------------------------------------------------------ |
| `*.mixpeek.com` | Core API (`api.mixpeek.com`), authentication (`auth.mixpeek.com`), and the app itself (`studio.mixpeek.com`) |
| `*.mxp.co` | Mixpeek content-delivery domain the app calls at runtime |
| `js.stripe.com`, `*.stripe.com` | Billing and checkout (Stripe) |
| `*.amazonaws.com` | Media and file delivery — Studio fetches content over signed Amazon S3 URLs |
| `*.googleapis.com` | Media and file delivery — Studio fetches content over signed Google Cloud Storage URLs |
Allowlisting only `*.mixpeek.com` is a common partial fix: the app then **loads
and signs in, but thumbnails, video, and file previews stay blank** because media
is served over signed `*.amazonaws.com` / `*.googleapis.com` URLs. Include the
storage domains, or evaluators will conclude the product is broken when it is only
blocked.
### Scoped storage hosts for strict environments
If your policy does not permit whole-provider wildcards like `*.amazonaws.com`,
replace the two storage entries above with these narrower hosts. They cover all
media delivery and nothing else — no other AWS or Google service:
| Instead of | Allowlist |
| ------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `*.googleapis.com` | `storage.googleapis.com` — the single host all signed media resolves to |
| `*.amazonaws.com` | `s3.*.amazonaws.com`, `*.s3.amazonaws.com`, `*.s3.*.amazonaws.com` — Amazon S3 only (path-style and virtual-hosted, all regions), e.g. `your-bucket.s3.us-east-2.amazonaws.com` |
Two `googleapis.com` hosts are needed **only if** you sync from Google Drive
(`drive.googleapis.com` and `www.googleapis.com`, for the connector's OAuth scope).
They are **not** required to view media — leave them out of a viewing-only
evaluation. If you bring your own object storage, media resolves to *your* bucket
host instead; allowlist that host.
## Optional — enhances the experience, not required
The app is fully usable without these. Allowlist them to enable in-product analytics,
support chat, and error reporting:
| Domain | Purpose |
| --------------------------------------------------------------- | --------------------------- |
| `*.posthog.com` (`us.i.posthog.com`, `us-assets.i.posthog.com`) | Product analytics |
| `*.intercom.io`, `*.intercomcdn.com` | In-app support chat |
| `*.ingest.us.sentry.io` | Client-side error reporting |
| `*.cloudflareinsights.com` | Performance telemetry |
## Protocols and ports
| Requirement | Value |
| ---------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Protocol | HTTPS |
| Port | 443 |
| WebSockets | Allow `wss://` to the domains above (Studio uses live connections for some features) |
| TLS interception | If your proxy does TLS/SSL inspection, it must present a certificate the browser trusts **and** preserve the allowlist above; deep-inspection proxies frequently strip the calls that break the app |
## How to confirm it's a network block (not Mixpeek)
Have the affected user, on the corporate network:
In Studio, open DevTools (F12 or ⌘⌥I) → **Console** and **Network** tabs, then reload.
Requests to `api.mixpeek.com` (or the domains above) showing `blocked`,
`net::ERR_BLOCKED_BY_CLIENT`, a CSP violation, or a proxy error page — rather than
a normal `200`/`4xx` from Mixpeek — confirm the network is dropping them.
The same account on a non-corporate network (or personal hotspot) loading normally
is definitive: the account and the service are fine; the corporate network is the
variable.
Fastest path for an evaluation: allowlist the **Minimum** table above and reload.
If sign-in works but media is blank, you're missing the two storage domains.
## Still blocked?
If the domains are allowlisted and Studio still won't load, contact
[support@mixpeek.com](mailto:support@mixpeek.com) with the browser console's Network
tab (screenshot or HAR export) — the blocked request URLs tell us exactly which rule
is still catching them.