API addresses and connectivity

Quick reference for your hosting provider

For a plugin or server that cannot send evidence, check outbound access from that server to MetricPoints. Use the addresses below and the full URL in your site's setup instructions.

Collector API base

https://metricpoints.com/api

Collector hostname

metricpoints.com

Main application / legacy API base

https://metricpoints.com/api

Production transport

HTTPS, outbound TCP port 443. DNS resolution must also work through your server's configured resolver.

Allow the collector hostname. Keep the main application hostname allowed for older installations and the WordPress plugin's supported fallback. These addresses reflect this installation's configuration; a custom installation override may use a different URL.

Use hostname-based rules where supported. API destination IPs can change or sit behind a proxy; the monitoring server IP list is not an API destination allowlist. If your firewall accepts only IP addresses, ask support to confirm current destinations before setting a fixed rule.

Check from WordPress

With plugin 1.3.3 or later, open Settings → MetricPoints → Check API access. It tests ingest.metricpoints.com and metricpoints.com separately from your WordPress server, without a key. If only the main host works, investigate access to the ingest host even if Verify connection succeeds through fallback. Custom API overrides are not tested. Use Verify connection separately to check credentials.

Which host should be used?

metricpoints.com serves the dashboard, sign-in, and documentation. ingest.metricpoints.com is the dedicated collection host when enabled. Older installations and compatibility fallbacks can still send reports to the main host; use the generated setup URLs instead of replacing hostnames manually.

The WordPress plugin accepts an assigned API host. Its beacon script loads from the ingest host, while collection follows the selected API base. Standalone beacon defaults can still use the main host unless explicit endpoints are supplied. The easy-install script supports data-ingest-origin; loading a script from ingest alone does not select its collection host.

The Linux server agent currently uses the main application host for both API traffic and signed update downloads. Keep that host reachable and use its generated installation command. Changing its base to ingest is not yet a supported way to split those responsibilities.

Check from the affected server

This read-only check needs no API key and does not submit monitoring data. Run it from the same server or container as the affected integration.

curl --connect-timeout 10 --max-time 20 --include 'https://metricpoints.com/api/test-connectivity'

Expect HTTP 200 and JSON containing "status":"success". This proves basic connectivity only; it does not verify credentials, collection permissions, or that evidence was stored.

• Could not resolve host: check DNS on the affected server.
• Timeout or connection refused: check outbound firewall rules, proxy configuration, and routing.
• Certificate error: check the server clock, CA certificates, and any TLS inspection. Keep certificate verification enabled.
• 403 or an HTML challenge page: review proxy/WAF logs for that host and path.
• Connectivity succeeds but reports fail: inspect the actual endpoint response and follow authentication and request limits.

Which paths does an integration use?

Paths below are relative to the collector API base. Allow only the integration you use; keep its authentication in place.

• Connectivity: GET /test-connectivity.
• Browser / CSP: POST /error-reports/{site-key}, POST /csp-reports/{site-key}, and POST /performance-sessions/{site-key} or PUT /performance-sessions/{site-key}. Browser error and performance collection also support OPTIONS preflight requests.
• WordPress: POST /v1/verify-api-key, POST /v1/wordpress/register, POST /v1/wordpress/check-in, and POST /v1/wordpress/action-results. Optional policy/header features also use /v1/csp-projects/….
• Server agents: setup-specific GET and POST requests under /v1/server-agents/.

If MetricPoints cannot check your website

That is the opposite direction: inbound requests from our monitors to your website. See Monitoring IP addresses for narrowly scoped firewall exceptions.

For browser-only failures, check the browser console and your site's CSP as well: beacon requests need the collector origin permitted in connect-src, while the script's host belongs in script-src. A successful server check does not prove that a visitor's browser can send reports.