Login Matching Versus Exact Credential Matching
Understand which question each Antipublic matching mode answers using synthetic records.
A reference database lookup can ask whether a login exists or whether a particular credential pair exists. Those questions can produce different answers for the same input. Antipublic exposes matching modes so you can choose the question your workflow actually needs.
A database match does not test a live sign-in. Keep reference membership separate from account access when interpreting either a match or an absent result.
Choose the question you need answered
Login matching asks whether the login is present, regardless of the password submitted with it. Exact credential matching requires both the login and password to match the reference record.
Host matching adds the canonical hostname to that comparison. It is useful when a URL record’s host forms part of the lookup key. Subdomains remain distinct.
Choose the mode before interpreting counts. Comparing results from different modes without recording the mode can make an expected difference look like a checker failure.
Compare the same sample in each mode
Suppose a synthetic reference record contains [email protected]:example-one. Your input
contains [email protected]:example-two. These are invented examples, not account credentials.
| Lookup mode | Result for this example | Reason |
|---|---|---|
| Login | Present | The login exists in the reference record. |
| Login + password | Absent | The submitted password differs. |
An absent exact pair does not contradict a present login. Each result answers the key comparison selected for that operation. Neither establishes whether either password works.
For URL records, compare two synthetic inputs that share a login and password but have different hosts. Host mode can distinguish them even when credential-pair mode does not. Record which dataset and comparison mode were used.
Use a small representative sample when setting up a recurring workflow. Confirm the parser’s accepted row shape and review rejected rows before interpreting the membership results.
Interpret a match in context
Public or present means that the selected key was found in the reference dataset. Private or absent means it was not found when that checked batch ran. Absence does not prove that the record is safe, newly created, unique across the internet or able to sign in.
Antipublic reads input locally and sends parsed lookup batches to the membership gateway. Optional private-row upload is a separate setting with a separate effect: eligible absent records are added as checked batches complete. Review that setting deliberately.
Malformed rows and unchecked input belong outside the absent result. An incomplete run cannot establish membership for its remaining rows. Keep the operation’s completion state with the files.
Use the related result guide to interpret saved files and interrupted runs. The product documentation explains accepted input forms, host normalization and request limits.
