Skip to main content
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:
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:
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:

​
Protocols and ports

​
How to confirm it’s a network block (not Mixpeek)

Have the affected user, on the corporate network:
1

Open the browser developer console

In Studio, open DevTools (F12 or ⌘⌥I) → Console and Network tabs, then reload.
2

Look for blocked requests

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.
3

Compare off-network

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 with the browser console’s Network tab (screenshot or HAR export) — the blocked request URLs tell us exactly which rule is still catching them.