API Callbacks

The VMP Security plugin mostly initiates outbound requests to our infrastructure. A small set of features require us to make inbound requests to your site instead — for example, verifying your visitor-IP detection by hitting your site from outside, or starting a scan when your site cannot trigger its own scan via WP-Cron. This article covers how to identify and allow those inbound calls if your site or hosting environment filters them.

In This Article

• What API callbacks are
• Identifying callbacks in your logs
• Allowing callbacks through firewalls and CDNs
• Disabling features that require callbacks

What API callbacks are

An API callback is an HTTP request made from our infrastructure to your site. The plugin uses callbacks for a handful of specific things:

• IP detection verification. When you change the visitor-IP detection setting, we hit your site from outside to confirm the configuration is reading the IP correctly. URLs containing detectProxy in the path are this kind of check.
• Scan dispatch. If your site cannot start a scan from its own cron (because WP-Cron is disabled and no replacement cron is set up), Portal can trigger a scan by calling into the site.
• Portal sync. Sites connected to Portal periodically receive sync requests for configuration pushes, scan starts, or audit-log fetches initiated from Portal.

Most plugin features do not need callbacks at all — the rules updates, signature updates, vulnerability data, and license checks are all initiated by the plugin reaching out. Callbacks are reserved for the small number of features where outside-in verification is genuinely needed.

Identifying callbacks in your logs

Callbacks are easy to identify in access logs by their User-Agent strings. The plugin’s callbacks set one of these:

• VMP Security API/1.0 (+https://www.vmpsecurity.com/help/api-callbacks/)
• VMP Security Portal API v1.0

The User-Agent links back to this help page so a curious administrator looking at server logs can find context for the request without having to ask.

Callbacks come from a known set of source IPs in our outbound infrastructure. The current list is published in the Advanced information article, on a page kept up-to-date as we add or remove infrastructure. Always cross-reference an IP against the published list rather than treating the User-Agent string alone as authoritative; User-Agent strings can be forged.

Allowing callbacks through firewalls and CDNs

If your site is behind a CDN with strict bot protection, or if your host runs an aggressive WAF, our callbacks may be blocked. Symptoms include:

• The visitor-IP detection check on the All Options page reports that we cannot reach the site.
• Portal-initiated scan starts time out.
• Connectivity tests on the Diagnostics page show callback paths failing.

To fix, allowlist our outbound IP ranges in your CDN or host firewall. The current ranges are listed on the Advanced article’s Servers and IP Addresses section. Most CDNs have a documented procedure for adding source-IP allowlists; the procedure is the same regardless of which IP ranges you are allowing.

Disabling features that require callbacks

If you do not want to allow inbound callbacks at all (some sites have hard requirements that all traffic must come through specific channels), you can disable the features that need them:

• Skip the visitor-IP detection check; configure the IP source manually based on your knowledge of your CDN/proxy chain.
• Set up a real cron job that calls wp-cron.php on a 1-5 minute schedule, so scans dispatch from inside the site rather than needing an outside push.
• Do not connect the site to Portal. The plugin still works without Portal; you just lose the centralized-management features.

None of these are recommended unless you have a specific reason. Allowing the callback IPs is much simpler than working around them.