Reputation API

The reputation subsystem is a standalone Tools capability. SocialGPT can use it as a client, but SocialGPT does not own the reputation data model, API namespace, public frontend, or administration.

ReputationFactory is the backend service boundary. The public product name may change later, so the current reputation naming is a neutral technical name rather than a permanent brand decision.

The system 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 reputation API keeps the existing authenticated client contract for backwards compatibility. A signed-in Tools session or a bearer token with the existing SocialGPT AI scope can be used.

The access contract is shared by the canonical endpoints and the legacy SocialGPT aliases. Moving the API out of the SocialGPT namespace does not weaken or bypass authentication.

Look up reputation

Canonical endpoint:

GET /api/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 a client looked it up.

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

Canonical endpoint:

POST /api/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. ReputationFactory 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 authenticated/internal clients, but they do not directly overwrite the target's authoritative reputation status.

Legacy SocialGPT API aliases

Existing clients may continue to use:

• GET /api/socialgpt/reputation
• POST /api/socialgpt/reputation/reports

These are compatibility aliases only. They use the same controller behavior, ReputationFactory service, authentication, validation, payload, response format and access control as the canonical endpoints. New integrations should use /api/reputation.

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 reputation frontend

The canonical public surface is available at:

/reputation

Visitors can look up public URLs, domains, posts, and content and inspect the authoritative status without using SocialGPT.

Public record pages are available at:

/reputation/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.

The former /trust and /trust/targets/{id} paths remain available for backwards compatibility, but newly generated links use the canonical reputation paths.

Reputation administration

Administration is available at:

/admin/reputation

This area is independent from SocialGPT administration. 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 never change authoritative status automatically.

The former /admin/trust paths remain as compatibility routes for existing links.