← Back to docs

SocialGPT reputation API

SocialGPT reputation API

The SocialGPT reputation layer is the first backend foundation for the documented "Trustpilot for Social Media" direction.

It is designed for public content and public resources. It is not a rating database for people, profiles, user accounts, or individuals, and it must not be used as a surveillance system.

Status model

A reputation target can have one authoritative status:

  • trusted
  • questionable
  • bad
  • unrated

Community reports are stored separately from that authoritative status. A report does not automatically change a target from unrated to another state. Moderation decides authoritative state changes.

Supported target types are:

  • domain
  • url
  • post
  • content

Person-oriented target types such as person, profile, user, account, and individual are intentionally rejected.

Authentication

The endpoints use the same authenticated SocialGPT account flow as the Fact Verify archive. A signed-in Tools session or a bearer token with the SocialGPT AI scope can be used.

Look up reputation

GET /api/socialgpt/reputation

Query parameters:

  • url - required public HTTP or HTTPS URL.
  • target_type - optional, defaults to url.
  • platform - optional platform hint.
  • external_id - optional platform content identifier.
  • title - optional display title.

An unknown URL is returned as unrated without creating a database record merely because the browser visited it.

Example response:

{
  "ok": true,
  "target": {
    "id": null,
    "target_type": "post",
    "canonical_url": "https://example.test/post/1",
    "status": "unrated",
    "report_count": 0,
    "community_reports": {
      "trusted": 0,
      "questionable": 0,
      "bad": 0
    }
  },
  "policy": {
    "community_reports_change_status_automatically": false,
    "people_can_be_targets": false
  }
}

Submit or update a report

POST /api/socialgpt/reputation/reports

Required fields:

  • url
  • verdict - trusted, questionable, or bad.
  • reason

Optional fields:

  • target_type
  • platform
  • external_id
  • title
  • evidence_url
  • fact_verify_card_id
  • target_metadata
  • metadata

A user has one current report per reputation target. Submitting another report for the same target updates that user's existing report instead of stacking another vote.

If fact_verify_card_id is supplied, that card must belong to the authenticated user. The reputation layer references Fact Verify as supporting evidence; it does not duplicate the verification payload in a second archive.

Reports begin in pending state. Community totals can be shown to internal clients, but they do not directly overwrite the target's authoritative reputation status.

URL normalization

Fragments such as #comments are removed from the canonical identity. HTTP and HTTPS URLs are accepted, hosts are normalized to lowercase, and default ports are removed. Query strings are retained because they can be part of a content URL's identity.

For domain targets, the hostname is used as the identity so repeated URLs on the same host can refer to the same domain reputation target.

Public Trust frontend

The standalone public surface is available at:

/trust

This is the visitor-facing product frontend and does not require the SocialGPT browser extension. Visitors can look up public URLs, domains, posts, and content and inspect the authoritative status.

Public record pages are available at:

/trust/targets/{id}

Public pages only show moderation-approved community signals. pending and rejected reports, reporter identity, and other raw moderation material are not exposed. A linked Fact Verify card is only linked publicly when that card already has its own public share link.

Trust is exposed as its own service in the main navigation and on /services.

Dedicated Trust admin

Administration is available at:

/admin/trust

This area is separate from SocialGPT administration even though SocialGPT uses the same reputation backend. Administrators can:

  • filter and inspect reputation targets
  • review incoming community reports
  • inspect evidence URLs and linked Fact Verify material
  • moderate reports as pending, accepted, or rejected
  • assign authoritative status as trusted, questionable, bad, or unrated
  • record a status reason
  • store which administrator changed the status and when

Community reports still never change authoritative status automatically.