Detect repeat accounts without treating every shared IP as abuse

Multiple-account detection works when it combines device continuity, network context and your own account history. IPCheckHQ supplies the device and IP evidence; your application decides whether the pattern is ordinary household use, a managed workplace or deliberate abuse.

Create a free project Explore the API

Start with the free plan. No card required.

The same IP is not the same user

Households, offices, universities and mobile carriers put many people behind one public address. Blocking every repeated IP creates support tickets while experienced abusers simply change networks. Email aliases and cleared cookies are equally weak when used alone.

A better rule asks several questions: has this project-scoped device ID appeared before, how quickly were the accounts created, does the network look residential or hosted, did the browser timezone change unexpectedly, and are there corroborating payment or profile signals? That produces a reviewable pattern rather than a fragile blacklist.

What you can build with it

Link events, not people

Associate repeated observed devices with your internal attempts while keeping identity claims deliberately narrow.

Reduce shared-network false positives

Use device and account evidence before penalizing everyone behind a home, office or carrier IP.

Choose graduated responses

Allow, rate-limit, require a card, request phone verification or review based on the strength of the combined pattern.

A short path from browser to backend

1
Collect at account creation
Create the verification token when the form is submitted and exchange it before granting the protected benefit.
2
Check relevant history
Look for the device ID, recent network activity and account attributes in the time window your policy defines.
3
Record the reason
Store which rules added friction so support and risk teams can understand and correct a mistaken decision.

Representative exchange response

POST /api/verify/v1/exchange

{
  "device": {
    "id": "dev_7da…",
    "visitor_id": "f8c…",
    "confidence": 0.97,
    "canvas_hash": "sha256:…",
    "webgl_hash": "sha256:…"
  },
  "network": {
    "asn": 13335,
    "network_type": "residential",
    "vpn": false,
    "hosting": false
  },
  "consistency": {
    "timezone_matches_ip": true
  }
}

Limitations worth designing for

One physical device may be shared by family members, students, employees or customers of a public terminal.
A new device ID does not prove a new person; attackers can change browsers, profiles or devices.
Device and network signals should support an account policy, not silently replace one.

Privacy is part of the implementation

Define what counts as abusive multiple-account behavior before collecting data, tell users where appropriate, and avoid indefinite link histories. A legitimate user affected by a rule should have a clear way to verify or appeal.

Read the IPCheckHQ privacy approach

Practical questions

Can IPCheckHQ tell whether two accounts belong to one person?: No. It can show that account events share an observed device or network context. Ownership is a conclusion your application must not make from one signal.
What should happen after a repeat is found?: Use a proportionate response such as requiring a payment method, delaying a benefit or sending the attempt to review.

Test the workflow in your own application

Create a project, allow your development origin and complete the first token exchange before choosing an enforcement rule.

Create a free project