How to Choose a VexSolver Endpoint

Start with the request you need to make

A web page, a native mobile API, and a sensitive application action can require different results. Identify the target vendor, the request method, the expected response, and how the application delivers cookies or headers. A token generated for one channel is not automatically valid in another.

The current public offering lists DataDome, PerimeterX / HUMAN, Imperva / Incapsula, and Kasada. Check availability with support for upcoming vendors and unfamiliar deployments. A documentation example is not a guarantee that every target configuration is supported.

Use the standard web solve for a URL-based workflow

POST /api/solve accepts the target and documented session inputs. It returns a task ID rather than holding the connection open until the challenge finishes. Poll the result endpoint at the documented interval, or provide a webhook callback. Consume the final result only after the task reaches its terminal state.

This is a useful starting point when you want the service to perform the challenge network flow. Consult the solve reference and your vendor guide for the required fields, returned cookie set, and verification information.

Use a payload workflow when your client owns the session

A payload transformer returns material your own HTTP client sends to the vendor. Your client remains responsible for the TLS session, proxy egress, cookie jar, and subsequent challenge responses. This gives you control of the network session but requires more integration work than receiving a finished solve result.

The Kasada reference and PerimeterX reference describe their respective payload workflows. They have different inputs and round trips; do not reuse one vendor's contract for another.

Distinguish PerimeterX web, mobile, and elevation flows

• Web integrations consume the documented cookie set.
• Native-app integrations use the mobile endpoint and its returned header bundle. A mobile result is not interchangeable with a web cookie.
• A protected action may issue a fresh challenge even when browsing works. Use the documented generation or block-solving workflow and preserve its session inputs.

Check which verification fields the selected endpoint returns. An issued cookie, a cleared page, and a successful protected application action are different outcomes. Validate the action you intend to perform.

Plan replay, billing, and failure handling together

If you need a server-side replay path, review forwarding and its supported contract. Otherwise replay through your own client with consistent egress and identity. Review credit behavior for the exact endpoint rather than assuming that all calls have the same cost or refund rules.

Begin with a small test against the real target, handle terminal failures explicitly, and bound retries. Once the contract works, increase concurrency gradually and monitor both task latency and target acceptance.