Skip to content
Prevu3D

Network Requirements

Using the RealityConnect API requires outbound HTTPS access to the hosts listed below. This page covers the full network path: what must be reachable, how proxies and TLS inspection affect connections, and how to tell a network problem from an authentication problem.

Requirements summary

Section titled “Requirements summary”
  • Outbound only, over HTTPS (port 443). No inbound ports, firewall rules, or NAT are required. See Inbound access.
  • Allow outbound HTTPS to the hostnames below.
  • A standard corporate forward proxy works transparently, including one that requires authentication. See Forward proxies.
  • A TLS-inspecting (SSL-decrypting) proxy will break connections unless its root certificate is trusted by the integration’s runtime. See TLS-inspecting proxies.

Inbound access

Section titled “Inbound access”

Nothing needs to be opened inbound to use the RealityConnect API. Your integration always initiates the connection outbound to Prevu3D; Prevu3D never opens a connection back into your network. There is no webhook, callback URL, or listener to register, and no inbound firewall rule to create.

Outbound access

Section titled “Outbound access”

Your integration must reach three kinds of hosts over outbound HTTPS:

  • OAuth and API discovery: https://cloud-api.prevu3d.com
  • Your regional RealityConnect API host, exactly one of:
    • https://api-ue1.prevu3d.com
    • https://api-ec1.prevu3d.com
    • https://api-an1.prevu3d.com
    • https://api-cc1.prevu3d.com
  • File transfers: https://cdn.prevu3d.com (downloads) and Amazon S3, *.amazonaws.com (presigned upload URLs)

Which region is mine?

Section titled “Which region is mine?”

Your organization is provisioned in exactly one region, so you do not need to allow all four hostnames. Rather than guessing or asking support, have your integration call the discovery endpoint (GET /oauth/api-info, described in each OAuth flow guide) once you have a token: the response’s apiUrl field tells you which regional host your organization actually uses. Allow that one hostname; you can skip the other three.

Forward proxies

Section titled “Forward proxies”

The RealityConnect API is a standard HTTPS/JSON API. It does not require anything unusual from the network path, and it does not do anything (such as certificate pinning) that would prevent it from working through a standard corporate forward proxy.

Whether your integration actually uses your proxy comes down to the HTTP client library it’s built on, not RealityConnect API:

  • Most HTTP clients (curl, Python requests, Node’s undici/fetch, .NET’s HttpClient, etc.) respect the standard HTTPS_PROXY / HTTP_PROXY environment variables, or an equivalent proxy setting in the client’s configuration. Check your client library’s documentation to confirm.
  • Authenticated proxies (ones that require a username and password) are also handled at the HTTP client layer, using the same proxy credentials mechanism the client already supports for any other HTTPS destination. RealityConnect API has no special requirement here. If your client can already reach other HTTPS services through your authenticated proxy, it can reach RealityConnect API the same way.

TLS-inspecting proxies

Section titled “TLS-inspecting proxies”

Some corporate networks run a TLS-inspecting (SSL-decrypting) proxy: it sits in the middle of the connection, presents its own certificate to your integration instead of Prevu3D’s, and re-encrypts traffic to the real destination. This is a known source of connection failures for API integrations in general, RealityConnect API included.

How it presents: instead of a clean response, your integration’s HTTPS call fails during the TLS handshake with a certificate validation error. The exact wording depends on your HTTP client and OS, but commonly looks like “unable to verify the first certificate,” “certificate verify failed,” “unknown certificate authority,” or a generic connection-reset error with no HTTP status code at all (because the request never got far enough to receive one).

What this means: your integration’s runtime doesn’t recognize the certificate the inspecting proxy is presenting, because it doesn’t trust the internal Certificate Authority (CA) that proxy uses to re-sign traffic.

Required fix, one of:

  1. Add the corporate root CA to the trust store the integration actually uses. This is the most common fix, and the most commonly missed step: many runtimes (Java, Node, Python) ship or load their own CA bundle instead of the operating system’s. Installing the corporate root CA into the Windows certificate store does not automatically cover them. Check whether your language/runtime needs its own configuration (for example, a NODE_EXTRA_CA_CERTS environment variable, a -Djavax.net.ssl.trustStore JVM flag, or adding the certificate to the bundle your Python requests/certifi installation uses).
  2. Exempt the RealityConnect API hostnames from TLS inspection, if your proxy supports per-destination bypass rules. This is often simpler than fixing every runtime’s trust store individually.

The right option depends on the proxy vendor and the integration’s runtime.

Diagnosis: is it the network or is it auth?

Section titled “Diagnosis: is it the network or is it auth?”

Work through these four checks in order. Each one isolates a different layer, so you find out where the problem actually is instead of debugging authentication code for a network issue (or vice versa).

1. DNS

Section titled “1. DNS”

Confirm the hostname resolves at all:

nslookup api-ue1.prevu3d.com

(Replace with cloud-api.prevu3d.com or your organization’s regional host as needed.) If this fails or times out, the problem is DNS resolution. Check the machine’s DNS configuration before going further.

2. TLS handshake

Section titled “2. TLS handshake”

Confirm a secure connection can be established to the host, independent of any Prevu3D-specific request:

curl -v https://cloud-api.prevu3d.com

Look for SSL certificate problem, unable to get local issuer certificate, or a connection that resets before any HTTP response. These all point to a proxy or firewall issue on the network path (see TLS-inspecting proxies above), not to anything in your integration code. A response with an HTTP status code, even an error one like 401, means TLS succeeded and the problem is further up the stack.

The curl that ships with Windows uses the Windows certificate store, so this check can pass even when a runtime with its own CA bundle (Node, Python, Java) still fails behind a TLS-inspecting proxy. If it passes but your integration reports a certificate error, see TLS-inspecting proxies.

3. Token request

Section titled “3. Token request”

Confirm you can obtain an OAuth access token. This checks that your credentials and OAuth request are well-formed, independent of any RealityConnect API call:

curl -v -X POST https://cloud-api.prevu3d.com/oauth/token \
  -u "<client_id>:<client_secret>" \
  -d "grant_type=client_credentials"

A 403 (wrong secret) or 404 (unknown client ID) here is a credentials problem, not a network problem, since DNS and TLS already succeeded to get this far.

4. First authenticated call

Section titled “4. First authenticated call”

Confirm the token actually works against the API:

curl -H "Authorization: Bearer <access_token>" https://cloud-api.prevu3d.com/oauth/api-info

A successful JSON response here confirms the full path (DNS, TLS, and authentication) is working end to end. A 401/403 at this step, after step 3 succeeded, points to a scopes or permissions problem rather than a network or credentials one. (/oauth/api-info requires the read:basic scope.)

What’s next?

Section titled “What’s next?”
  • Getting Started: prerequisites, the security model, and choosing an OAuth flow.