Cross-source OSINT aggregation
One identifier in,
one reconciled view out.
CrossTrace takes a single seed — an email, a username, a phone number, a domain — fans it across every OSINT API you hold a key for, and merges what comes back. Not three lists side by side: one deduplicated set of accounts, one identity profile with every value attributed to the source that asserted it, and a map that draws exactly as much precision as the source actually offered.
Bring your own API keys. AES-256-GCM at rest, scoped to your account, never shared between accounts.
Recorded run
one seed identifier · two APIs · measured, not modelled
01Fan-out
One seed, every source you hold a key for
Queries run in parallel and stream as they land, so the first useful result arrives long before the slowest API has finished.
Seed
one identifier
- username
- phone
- domain
In parallel
- OSINT.Industries
- Opsis
- Dehashed
written, not yet wired in
- IntelX
- Leak-Lookup
One view
- deduplicated accounts
- cross-source identity profile
- breaches, under one heading
- location at source precision
- pivots for the next search
Sources are declared in one registry, and everything downstream reads from it — badges, per-source counts, map colours, filters. Adding an API is a client and one entry, not a pass over the interface. It is also why the row above is not a list somebody has to remember to update: it is the same declaration the application renders from.
A source that cannot accept the identifier type in front of it is skipped rather than queried, and the skip is reported rather than hidden. Two of the three live sources take a phone number; one takes a street address. Asking the others anyway costs a call that could not have matched and returns a silence you then have to interpret.
02Merge
Corroboration, not concatenation
An account two APIs both found becomes one card marked corroborated — not two rows that read like two findings.
Three source lists side by side leave the reconciling to the analyst, and reconciling is where the mistakes live. The same Quizlet account reported by two APIs used to render twice, in two different places, with nothing to say it was one account. Read at speed, two rows look like two independent confirmations. They are one account, seen twice.
CrossTrace keys accounts on what the account is— platform plus the identity within that platform — rather than on who reported it. On the recorded run, 72 raw account records from two APIs collapsed to 44 distinct accounts, 15 of them carrying more than one source’s name. Corroboration becomes a property of a single card, which is the only form in which it means anything.
Raw — as the APIs returned it
- Quizlet
- Adobe
- Strava
- Quizlet
- Poshmark
5 records · Quizlet appears twice · read quickly, that looks like two findings
Merged — keyed on what the account is
- Quizletcorroborated ×2
- Adobe
- Strava
- Poshmark
4 accounts · one of them a genuinely stronger claim than the rest
Merging is not flattening. A merged account still renders through whichever source had the most to say about it; only the grouping is unified. What changed is that the other source’s data stopped being thrown away. Previously, when two sources described the same account, the loser’s fields were fetched, deduplicated, and then silently dropped at render — 92 of them on the recorded run.
Among them: Adobe’s MFA state, a Poshmark account whose registration_method revealed it had been created with Google sign-in, and a Gravatar md5 that hashes a different address than the SHA-256 already on the card. Each was fetched, paid for, and never shown.
03Ranking
Ordered by what you can do next
Not by which API answered, and not by the order the bytes arrived.
A field’s position on a card is a claim about its importance, so the claim should be earned. Pivotable identifiers lead, because they are what starts the next search. Security posture follows, because it is what makes an account exposed. Then who the person is, then whether the account is still alive.
- 10s
Pivotable
starts the next search- email hint
- phone hint
- username
- user id
- md5
- sha256
- wallet
- 20s
Security posture
how exposed the account is- mfa
- password
- federated auth
- saml sso
- status
- signup method
- 30s
Identity
who it is- name
- location
- age
- language
- bio
- website
- 40s
Presence and activity
whether it is live, and since when- created
- last seen
- followers
- posts
- verified
- 90
Unrecognised
kept, below the fold, never discarded- has_passkey
- webauthn_rp_id
- prefer_external_idp
- …
Fields nobody has seen before still land in the right band. One run produced 94 field names the tool had never encountered — has_passkey, webauthn_rp_id, prefer_external_idp, followed_species— so an unknown key is classified by the tokens in its name and, failing that, by the shape of its value. It keeps its own label; only its rank is inferred. Nothing is renamed and nothing is dropped.
Values that say nothing keep their category and sink below the fold, because ranking on category alone floods the top of a card with false flags and zero counters. code login available: no is a platform capability that happens to be off. mfa: no is a finding, and is exempt from the demotion.
04Identity
Attributed values, surfaced conflicts
Every value carries the sources that asserted it. Where sources disagree, you are shown the disagreement.
The identity profile is assembled from every source at once — name, username, email, phone, location, photo — and it leads the overview, because it answers the question the search was asked. It replaced a single-source panel that sat at the bottom of the page and could only ever show what one API returned.
Where sources disagree, the most-corroborated value leads and the alternatives sit one click behind it, labelled with how many candidates exist. Nothing is silently resolved.A merge that quietly picks a winner has made a judgement on the analyst’s behalf in a place they cannot inspect — and a disagreement between two sources is often the most interesting thing on the page.
Identity — one field, three assertions
- name
- Jane A. Doeleads: two sources agree
- OSI · Opsis
- name
- J. Doekept as a candidate, one click away
- Dehashed
- location
- Country: US · State: HIregion precision — drawn as a state outline
- OSI
05Location
A country-level claim is a country-shaped claim
Precision is parsed, never assumed. It picks the geometry, and the geometry is the only honest summary of how much the source knew.
Geocoding is where OSINT tooling quietly invents things. Raw: United States resolves to a point in Kansas. Country: US, State: HIresolves to open water in the Pacific. Drawn as pins, both assert a precision no source ever offered — and a pin on a map is the most persuasive object in an intelligence report.
So every location claim is parsed into an explicit precision first, and the precision decides the geometry. A point where a point was given; a state outline for a state claim; a country outline for a country claim; the real IANA boundary for a timezone.
What the source said
What the map draws
coords · address · city
- 17471 78th ave n 55311
- City: Long Lake Country: us State: MN
a point
region
- US, HI
- Country: US State: HI
the admin-1 outline — the actual state boundary
country
- Raw: United States
the admin-0 outline — the whole country
timezone
- America/Chicago
the real IANA timezone boundary
The sources agree on nothing about format. One recorded run produced six distinct shapes for the same kind of fact — a labelled blob, a country-first pair, a city-first pair, a bare street address, structured metadata keys, and pre-resolved coordinates. Precision is what survives that parse, and it is the one thing the map is not permitted to guess.
06Output
What comes back, and where it goes next
One heading per kind of finding, and a route from any finding into the following search.
Breaches
Under one heading, whatever shape they arrive in
Providers agree on nothing here either — breach_count against leak_count, breaches[] against sources[] against sites[]. Breach findings from every source render under a single heading, shape-agnostic: every non-empty field the provider sent, in the order it sent them, with the count of anything skipped shown in the footer. A provider the tool has never seen renders exactly as well as one it has.
Pivots
Every discovered identifier is the next search
An email hint, a phone hint, a user id, a password hash found inside one platform’s record is a lead, and leads are ranked and launchable from the card that produced them. The results of a pivot merge into the view you are already reading rather than opening a second one, so a chain of five searches stays a single picture instead of five tabs to reconcile afterwards.
07Keys
Your keys, your credits
Bring your own API credentials. They are encrypted at rest with AES-256-GCM and never shared between accounts.
CrossTrace does not resell anyone’s API. You supply credentials for the providers you already pay for; they are encrypted with AES-256-GCM under a master key held in the deployment’s environment, never on disk beside them, and they are scoped to your account and never shared between accounts. The result cache is scoped the same way, so nobody else’s search is ever served from your credits — and yours is never served from theirs.
Premium tiers are not symmetric between providers — one applies its premium flag to every identifier type it accepts, another only to username searches — so the search form says which one you are actually buying, for the type in front of you, before you spend anything. Credit balances are read from the providers themselves, so what you see is what the API says you have.
Point it at one identifier and read what every source says at once.
You will need a key for at least one supported provider. Add it in Settings; the first search takes a few seconds.