SmartURLs V2 clients bring updated integration paths to PHP and Go

Stopbot has prepared dedicated SmartURLs V2 clients for PHP and Go. The new implementations preserve the familiar path-based SmartURLs experience while aligning request handling with the current service response and browser-verification flow.

Why dedicated V2 clients were needed

The original public SmartURLs application was built for the Legacy API response. Current SmartURLs responses use a different contract and can provide a uniqueCode when browser verification is enabled. Treating the two formats as interchangeable would make redirect and verification behavior unreliable, so the V2 clients implement the current contract directly.

• Path-based key names remain simple for publishers and campaign links.
• API credentials are configured outside public templates.
• Redirects follow the redirectTo value returned by the service.
• Browser verification uses the current unique-code flow when enabled.
• Local response templates handle invalid routes and unavailable service responses.

Browser verification stays bound to one response

When browser verification is enabled, the initial SmartURLs response can issue a uniqueCode. The V2 clients use that API-issued value for the local verification step instead of treating the public path key as the verification reference. This keeps the clean SmartURLs path responsible for routing while the verification result remains bound to the response that created it.

PHP for familiar hosting environments

The PHP client is intended for conventional web hosting and server deployments where PHP is already part of the stack. Its installation guidance covers application configuration and both Apache and Nginx routing, including the rewrite behavior needed to turn a clean path into a SmartURLs key name.

Go for a standalone service

The Go client packages SmartURLs as a standalone HTTP service. Configuration is supplied through environment variables, including the Stopbot API key, listen address, API endpoint, and trusted-proxy behavior. Deployment guides cover Nginx, Apache, Microsoft IIS, Caddy, and systemd so operators can place the service behind their existing web stack.

Consistent visitor-facing responses

Both clients include responsive local message pages for invalid paths and service failures. The refreshed presentation supports light and dark color preferences, keeps the Stopbot attribution visible, and avoids exposing raw API response text to visitors.

Choose the runtime that matches the deployment

Teams already operating PHP can adopt the PHP client with minimal infrastructure change. Teams that prefer a compiled, standalone process can use the Go client and place it behind their existing reverse proxy. In both cases, the SmartURLs configuration remains managed from Stopbot and the client applies the current service decision.