OSINT API for Person Investigations

Runs an autonomous OSINT investigation across public sources and reconciles everything it finds into a single person report: identity, aliases, usernames, emails, phones, social accounts (including when an account was created and last seen active, where that is known), employment and education history, locations, websites, public content, public records, corporate roles, adverse findings, images, and wallets. Sections with no findings are omitted. images mixes photographs of the subject with reverse-image matches (reverse_match: true), and a reverse-image match is a page containing a similar image, which is not always the same person - where the faces could be compared, face_match reports match, different or inconclusive, with face_match_score (0-1) giving the strength of the correspondence. An inconclusive match is still returned - a comparison that could not decide is not evidence against the page - so check face_match before presenting any match as the subject; an absent face_match means no comparison result is available, not a negative result, and an unconfirmed entry carries no confidence so the score says none while face_match says why. A comparison that concluded the faces are different is withheld, because that is a finding rather than an absence of one. Requires at least one direct identifier (email, phone, social_media_url, username, or domain), or a name together with a company or city. mode selects how hard the agent works the search (shallow, medium by default, or deep) and therefore what it costs; the retired depth parameter is rejected with 400 rather than silently downgraded. A search keeps running server-side for up to 30 minutes, so poll about every 10 seconds or supply a callback_url. If that window closes while the run is still working, whatever it had already assessed is returned and billed like any other result - reaching the limit is how depth is bounded, not a failure - including records it had gathered but not yet judged, which arrive as leads at zero confidence with UNADJUDICATED_CANDIDATES raised. A run cut short before it had assessed anything at all returns nothing and is reported as failed, because records no adjudication has looked at are not findings about your subject; those are never returned. A failed request returns result too whenever the run got far enough to produce diagnostics, holding report_quality and reconciliation_summary and nothing else - so the error is not all you get. It never carries anything about the person: a run that produced data about the subject is a success, so an error and person data never arrive together. A run cut short before adjudication began has no diagnostics either, and then result is absent entirely. result.report_quality describes the report you are holding so you can filter it in code rather than by eye: flags is a list of stable terms naming what is present (DISPUTED_RECORDS_PRESENT when an independent review rejected some returned records, UNCONFIRMED_RECORDS_PRESENT when review could not confirm them, UNADJUDICATED_CANDIDATES when records were gathered that nobody adjudicated - those are returned at the lowest confidence among emails, phones, usernames, social_profiles, locations, wallets and images, so treat them as leads - every adjudicated item carries a confidence above zero and every lead carries exactly zero, so confidence > 0 reliably keeps only the adjudicated results. An item is never scored down for something we merely could not label: an account on a site we cannot name keeps its confidence and reports platform: unspecified instead, ROLES_DERIVED when a record's category was inferred from its type, LOW_CONFIDENCE_RECORDS_PRESENT when some records scored below the floor the policy considers strong and are returned at their own score rather than withheld), sized by disputed_count and unconfirmed_count. Records are never withheld to express a flag - a disputed record is returned with its confidence capped at 0.1 and an unconfirmed one at 0.35 instead of being removed, so you can filter by score or by term. Zero - or the field being absent, since a zero double is not transmitted - means one thing only: nobody adjudicated the record. confidence > 0 therefore keeps just the adjudicated results in any JSON consumer, and a strict typed reader should treat a missing confidence as zero. A confirmed record carries the adjudicating model's own confidence, usually well above those caps but not guaranteed to be, so treat the numbers as a scale to threshold on rather than as ranked tiers. A report with no caveats omits flags entirely. resolution_status says how the investigation ended. complete means records were accepted and the report holds findings - it is reported whenever anything was accepted, including when the search was cut short by its time budget or salvaged after a failure, so read unreviewed_count and flags rather than this field to judge how complete the sweep was. no_match means the search ran and concluded none of the candidates was the subject - a finding rather than a failure, and not billed when the report holds nothing but that verdict. budget_exhausted and adjudication_failed both mean nothing was accepted. None of these three is decided by resolution_status alone: whether a request succeeds, is billed, and answers 200 depends only on whether the report carries data about the person, so a run that gathered leads before it ran out of budget or failed adjudication still returns them, still bills, and still answers 200 - with the leads at zero confidence and UNADJUDICATED_CANDIDATES raised. Only a report with nothing in it at all is reported as failed, and that one is never billed. degraded means findings alongside candidates never judged either way, which you see on a partially-complete result rather than a finished search, and unspecified means the run had not reached a resolution when the result was stored - you see that on a partial salvaged from a search that failed, was cancelled, or was cut short by the poll window partway, where the findings present are still real. This endpoint is disabled by default for every account - see Access below before you integrate it.

{
  "success": true,
  "data": {
    "request_id": "a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4_1717000000_4271",
    "status": "processing",
    "message": "OSINT deep search request submitted. Use GET with request_id to check status.",
    "created_on": "2026-01-15T10:45:02"
  },
  "timestamp": "2026-01-01T00:00:00"
}

{
  "success": true,
  "data": {
    "request_id": "a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4_1717000000_4271",
    "status": "completed",
    "completed": true,
    "created_on": "2026-01-15T10:45:02",
    "completed_on": "2026-01-15T10:52:31",
    "result": {
      "identity": {
        "name": "Jane Doe",
        "kind": "person",
        "labels": [
          "product leadership"
        ],
        "confidence": 0.92,
        "identifiers": [
          {
            "value": "jane.doe@acme.com",
            "confidence": 0.95,
            "best": true
          }
        ]
      },
      "aliases": [
        {
          "value": "Jane A. Doe",
          "kind": "legal",
          "confidence": 0.71
        }
      ],
      "usernames": [
        {
          "value": "janedoe",
          "platform": "github",
          "url": "https://github.com/janedoe",
          "confidence": 0.88
        }
      ],
      "emails": [
        {
          "value": "jane.doe@acme.com",
          "kind": "work",
          "verified": true,
          "confidence": 0.95
        }
      ],
      "phones": [
        {
          "value": "+15551234567",
          "kind": "mobile",
          "verified": false,
          "confidence": 0.62
        }
      ],
      "social_profiles": [
        {
          "platform": "linkedin",
          "url": "https://linkedin.com/in/janedoe",
          "username": "janedoe",
          "display_name": "Jane Doe",
          "follower_count": 4200,
          "confidence": 0.93,
          "first_seen": "2026-01-15T10:47:10Z",
          "last_seen": "2026-01-15T10:47:10Z",
          "usage": {
            "created_at": "2011-03-08T00:00:00Z",
            "last_seen_at": "2026-01-10T00:00:00Z"
          },
          "registered": true,
          "verified": false,
          "platform_variables": {
            "headline": "VP of Product at Acme"
          }
        }
      ],
      "employment_history": [
        {
          "company": "Acme",
          "title": "VP of Product",
          "start_date": "2023-04",
          "current": true,
          "confidence": 0.9
        }
      ],
      "education_history": [
        {
          "institution": "State University",
          "degree": "BSc",
          "field": "Computer Science",
          "confidence": 0.7
        }
      ],
      "locations": [
        {
          "city": "Austin",
          "region": "TX",
          "country": "US",
          "current": true,
          "confidence": 0.81
        }
      ],
      "websites": [
        {
          "url": "https://janedoe.dev",
          "title": "Jane Doe",
          "domain": "janedoe.dev",
          "confidence": 0.76
        }
      ],
      "public_content": [
        {
          "title": "Jane Doe on shipping AI products",
          "url": "https://example.com/interview",
          "description": "Interview covering product strategy at Acme.",
          "published_at": "2025-11-02T00:00:00Z",
          "confidence": 0.65
        }
      ],
      "images": [
        {
          "url": "https://records.example/subject.jpg",
          "confidence": 0.9
        },
        {
          "url": "https://social.example/p/abc",
          "source": "social.example",
          "description": "Matched profile page",
          "reverse_match": true,
          "similarity": 94.5,
          "source_image_url": "https://records.example/subject.jpg",
          "thumbnail_url": "https://thumbs.example/abc.jpg",
          "face_match": "match",
          "face_match_score": 0.87,
          "confidence": 0.93
        },
        {
          "url": "https://blog.example/post",
          "source": "blog.example",
          "reverse_match": true,
          "similarity": 71.2,
          "face_match": "different",
          "face_match_score": 0.04,
          "confidence": 0.4
        }
      ],
      "confidence": 0.88,
      "report_quality": {
        "resolution_status": "complete",
        "confidence_semantics": "heuristic_evidence_strength",
        "accepted_evidence_count": 14,
        "unreviewed_count": 2,
        "flags": [
          "UNADJUDICATED_CANDIDATES",
          "UNCONFIRMED_RECORDS_PRESENT"
        ],
        "disputed_count": 0,
        "unconfirmed_count": 3,
        "retry_count": 0,
        "fallback_count": 0,
        "policy_version": "identity-publication-v1"
      }
    }
  },
  "timestamp": "2026-01-01T00:00:00"
}