Gravatar's developer model distinguishes ordinary label-and-URL links from verified-account entries, which identify a service and linked profile and carry a visibility flag. Compare only the destinations actually shown on the public profile, keeping the two field types separate. A service-linked record indicates a platform connection; neither field verifies offline biographical claims or makes a private dating message authentic.
Find public social profile clues with our TraceSeek app.
Start with the field types, not the person
The Gravatar developer model lists ordinary label/URL links separately from verified-account entries, which identify a service and linked profile and have a visibility flag. This describes the data model, not a promise that a public profile displays every technical field. As a public reader, record the label, service and destination actually shown; do not seek hidden fields or assume the API schema is a new TraceSeek feature. [Gravatar Developer Docs: profile data models]
- List each visible destination under either ordinary link or verified-account entry.
- Keep the raw label text and the destination as they appear; do not rename them for neatness.
What each field can and cannot tell you
An ordinary label-and-URL link is a self-supplied pointer: the profile owner chose a label and a destination, and the pairing is public configuration. A verified-account entry is a service-linked record that names a platform and linked profile and carries a visibility flag in the developer model. Neither field type verifies offline biographical claims, and the profile schema itself is not evidence of identity, intent, or safe contact. [Gravatar Developer Docs: profile data models]
- Record what a field shows, then a separate line for what it does not establish.
- Mark a field not shown on the shared view as unavailable rather than as a negative finding.
Compare destinations without merging them
A useful comparison holds the field type constant. Compare ordinary link destinations against ordinary link destinations, and verified-account entries against verified-account entries. If the same destination appears both as a plain link and as a verified-account entry, note the overlap as a data point about the profile's configuration, not as confirmation of anything beyond the profile. Keep your map small and dated by your own notes so you can see what changed in the public record over time.
| observation | limit | next step |
|---|---|---|
| An ordinary link shows a label and a URL | It is self-supplied configuration; it does not verify the destination's owner or current activity | Record the label and URL verbatim; check nothing beyond the public page |
| A verified-account entry is visible on the public profile | It names a service and linked profile; the model includes a visibility flag | Note the service and destination as shown; do not infer intent |
| The same destination appears in both field types | Overlap describes the profile's public record, not offline identity | Log the overlap in your notes and move on |
| A field is not shown in the shared view | The schema may include it even when not displayed to you | Stop at the access boundary; do not seek another way in |
Handling unavailable fields without crossing a boundary
If the shared artifact does not show a field you expected, record it as unavailable and stop. That is the access boundary working as intended. Do not treat missing information as evidence of anything. If you need clarity, ask for a voluntary current link or consult the official current help for the platform in question. [Gravatar Developer Docs: profile data models]
A hypothetical worked example
Suppose a hypothetical shared profile lists an ordinary link labeled "writing" that points to a public page, and a verified-account entry naming a platform shown on the public profile. The correct reading is: one self-supplied label/URL pairing, and one service-linked record. You might note that the public page's author name matches the profile display name, but that observation is a coincidence in the public record, not verification of the same offline person. If a second entry were not shown, you would write "unavailable" and stop, rather than searching elsewhere to fill the gap.
- Keep the example's two field types in separate columns of your notes.
- Write one sentence on what each observation does not establish.
When to conclude and when to stop
Conclude when you have sorted every visible destination into its field type, recorded limits next to each observation, and checked whether any overlap changes what you can say. Stop when the remaining gaps concern offline identity, because that sits beyond what a public profile schema can answer. Your notes should read as a dated snapshot of public configuration, with decisions kept apart from observations.
- End the review with a dated summary of visible fields and their limits.
- If a gap remains, mark it unavailable and record the question you would ask the owner voluntarily.
A couple more questions
Is a verified-account entry stronger proof of identity than an ordinary link?
A verified-account entry and an ordinary self-supplied link describe different connection types. Neither is proof of offline identity. The profile schema does not verify offline biographical claims, so neither field type proves who someone is away from the profile. Treat both as public configuration items with different formats, not as levels of trust.
What should I write when a field I expected is not shown?
Write "unavailable" and stop at the access boundary. The shared view did not show it, and the schema alone does not tell you why. If clarity matters, ask the owner for a voluntary current link or check official help.
Can I compare a social link with the same destination on another platform?
You can note that the same public destination appears in both places, but describe it as an overlap in public records, not confirmation. Keep the field types straight on each profile, date your notes, and avoid inferring current activity or identity from the match.
Sources & editorial notes
Official references checked on October 23, 2026. Checklists, comparison tables and example wording are DateClues editorial tools, not official tests or validated risk scores.
General information. No guide or tool can certify a person’s identity, intentions or safety. Read our editorial standards.