Website traffic

POST /v1/traffic/visits delivers real page visits to a URL, with a controlled referral source, geo/device targeting, and human-like dwell and browsing. Billed $0.002 per delivered visit.

Request

curl -X POST https://api.serplify.io/v1/traffic/visits \
  -H "Authorization: Bearer live_your_key_here" \
  -H "Content-Type: application/json" \
  -d '{
    "url": "https://example.com/landing",
    "quantity": 5000,
    "source": "facebook",
    "geo": { "country": "US" },
    "device": "mixed",
    "dwell_seconds_min": 20,
    "dwell_seconds_max": 90,
    "bounce_rate": 0.4,
    "pages_per_visit": 3
  }'

Field	Type	Required	Default	Notes
url	string (URL)	yes	—	Destination the visit lands on.
quantity	integer	yes	—	Visits to deliver (1–1,000,000).
source	enum	no	organic	organic, direct, facebook, twitter, reddit, pinterest, linkedin, youtube, referral.
referrer	string (URL)	no	—	Custom referrer (for source: "referral").
geo	object	no	—	{ country? } — ISO-3166 alpha-2, country-level targeting.
device	enum	no	mixed	desktop, mobile, mixed.
browser_mix	string / object / null	no	omitted	automatic or browser percentages totaling 100. Omit or use null for the original Chrome delivery.
mobile_percent	number	no	30	Mobile share (0–100) when device=mixed and a browser mix is selected.
pacing	enum	no	asap	asap delivers as fast as capacity allows; distributed spreads delivery naturally over spread_hours.
spread_hours	integer	no	24	For pacing: "distributed": spread the quantity over this many hours (1–720).
dwell_seconds_min / dwell_seconds_max	integer	no	15 / 60	Time on the landing page.
bounce_rate	number	no	0.5	Fraction (0–1) that bounce after landing.
pages_per_visit	integer	no	1	Internal pages browsed (1 = landing only).
tag	string	no	—	Free-form label.

Response

HTTP 202 with a campaign whose product is visits. Poll status_url to watch delivered climb.

How visits behave

• Each visit is a real browser page load, so client-side analytics (GA4, etc.) register it.
• The referral source shapes the Referer and navigation pattern so the visit attributes to the chosen channel.
• geo and device route the visit through matching residential/mobile proxies.
• dwell_*, bounce_rate, and pages_per_visit shape realistic engagement.

You are charged only for visits actually delivered.

Browser profile mixing

Select the browser identity presented during visits independently of the traffic source. All visits still execute through Chrome; this setting changes user-agent, client-hint, and JavaScript navigator signals. Existing requests that omit browser_mix keep the original Chrome execution behavior. During rollout, explicit browser mixes are rejected until the service enables them; ordinary Chrome requests continue to work.

{
  "url": "https://example.com/",
  "quantity": 1000,
  "source": "direct",
  "device": "mixed",
  "mobile_percent": 40,
  "browser_mix": {
    "chrome": 60,
    "edge": 10,
    "firefox": 10,
    "safari": 20
  }
}

Custom percentages must total 100; omitted browsers receive zero. Chrome, Edge, Firefox, and Safari profiles support both desktop and mobile visits. Safari mobile uses iPhone signals; the other mobile profiles use Android signals. Unknown profile names and invalid percentages are rejected.

"browser_mix": "automatic" uses product presets adjusted to the device mix: 60% Chrome, 15% Edge, 15% Firefox, 10% Safari for desktop, and 70% Chrome, 5% Edge, 5% Firefox, 20% Safari for mobile. Mixed-device presets blend these in proportion to the mobile share. These are product defaults, not global market-share claims.

Browser profile and device selection is stable across retries while campaign settings stay the same. Percentages describe allocation targets across many visits, not exact quotas or guaranteed analytics counts. Delivery failures and small samples can change observed proportions. Profile emulation does not change Chrome’s underlying rendering or TLS engine; analytics classification depends on the target’s own tracking. The website’s normal analytics run during the visit.

Campaign creation/status responses include browser_mix, device, and the effective mobile_percent when browser mixing is enabled. Campaign settings can also be edited in the dashboard. Changes apply when subsequent tasks are claimed; already-running visits keep their current settings.

Verify profiles used for delivered visits

GET /v1/traffic/campaigns/{id}/browsers returns an account-scoped, unbilled breakdown of profiles on retained successful task records over the last seven days, inside the standard API envelope:

{
  "since": "2026-09-15T12:00:00.000Z",
  "until": "2026-09-22T12:00:00.000Z",
  "delivered": 100,
  "browsers": [
    { "browser": "chrome", "delivered": 70, "share": 70 },
    { "browser": "safari", "delivered": 30, "share": 30 }
  ]
}

Historical visits without browser attribution appear under browser: null. Failed attempts are excluded. The dashboard shows the same breakdown and the profile/device for each recorded delivery. The browser field identifies the presented profile, not a separate browser runtime. Subscribed delivered webhooks also include result.browser and result.device for campaigns that opted into a browser mix. Existing campaigns keep their original webhook payload.