Skip to main content

Compatibility Details

This page is for the cases where you need the exact detail about differences between the Perspective API and ours. It covers the two Perspective-compatible endpoints:

  • /v0.2/perspective-compat/analyse
  • /v0.2/perspective-compat/suggestscore

Requests and Responses

ItemSupportNotes
Perspective-style request formatSupportedKeeps the familiar request model
Perspective-style response formatSupportedReturned as closely as currently supported
Authentication with X-User-Email and X-API-KeySupportedReplace Perspective's query-string key
Canonical Perspective attributesSupportedCore moderation attributes are supported
Google aliases and experimental namesSupportedRequested alias names are preserved in responses
scoreThresholdSupportedApplied per requested compat attribute
scoreType=PROBABILITYSupportedA 0 to 1 score where higher means more of the requested attribute
Other scoreType valuesUnsupportedRejected deliberately rather than guessed
Google-style error bodySupportedReturned where the compat layer handles the error

If you are not sure how to read PROBABILITY, summaryScore, or spanScores, see Perspective Score Types.

Spans and Languages

ItemSupportNotes
spanAnnotationsSupportedspanScores are included only when requested
Span offsetsSupportedUTF-16 code units on escaped output text
languages when suppliedSupportedPreserved in the response
Language detection when languages is omittedNot claimedRespectify does not detect languages

If your interface uses spans directly, test with emoji, quotes, ampersands, and text that looks like HTML. Returned span text is escaped for safe display, and the offsets line up with that escaped text.

If you rely on language fields, the important rule is simple: Respectify preserves languages when you send them, and does not claim detection when you do not.

Context and Score Corrections

ItemSupportNotes
context.entriesSupportedText entries accepted
context.articleAndParentCommentSupportedFlattened into context comments
HTML text entriesSupportedtype: HTML is normalised to text
suggestscore summary scoresSupportedsummaryScore.value accepted
suggestscore span scoresPartially validatedAccepted and validated for score type, but stored correction remains summary-score based

Request Metadata and Storage

ItemSupportNotes
doNotStoreAcceptedAnalyse traffic is currently treated as though doNotStore were always true, because it is not retained for training
sessionIdAcceptedLogged for traceability, does not affect scoring
communityIdAcceptedLogged for traceability, does not affect scoring
dropUnsupportedAttributesAcceptedUnsupported attributes are already ignored in common compat flows

Feedback sent through suggestscore is stored intentionally, ie retained. That is the purpose of the correction endpoint.

We retain logs of each call (that it was made, which account, which endpoint, what it cost, and related info) which are required for our records, billing, etc, but we do not retain the content of what was scored - the text itself.