Reported Content API

Concepts

This guide assumes familiarity with the general usage patterns of the Workplace Graph API. The Reported Content API adds new graph objects to allow actioning of content reports which are presented in the Reported Content Workplace Admin Panel page.

These objects include:

• Content Report: Contains the information about the reporters and the reported violations of a particular content
• Reported Content: Contains some information about the type of the reported object and its content

Conventions

Below are a set of working assumptions regarding the conventions for encoding and validity of different parts of the API. These conventions are not duplicated throughout this document as are currently in review and subject to change:

1. Timestamps values (date time timestamp) are handled as UTC offset epoch milliseconds. The exact sub-second millisecond values may be quantised when returned.
2. Wherever possible the API will return error messages indicating errors, so on non-2XX responses please consult the API error messages for developer feedback. These are intended for the developer and should not be surfaced to regular users.

Permissions

The permission required to make calls to the Reported Content API is read_and_action_reported_content, though you may require other permissions in order to access the content being reported.

Core Flows

Once an instance administrator has enabled an integration with a case management tool (and that integration holds a valid access token) the case management tool can use its access token to sync Workplace content reports data to external cases and also propagate actions taken by moderators back to Workplace.

Reading Content Reports

Fetch the Content Reports of a company

GET /community/reported_content

This will return all unactioned reports within the company.

Read a single Content Report

GET /{content-report-id}

Content Report object fields

Read reported content

GET /{content-report-id}/reported_content

Reported Content object fields

Actioning Content Reports

Allow the reported content to stay on Workplace

POST /{report-id}/allow_content

This action removes the report and doesn’t affect the content.

Delete the reported content

POST /{report-id}/delete_content

This action removes both the report and the content.

Hide the reported content

POST /{report-id}/quarantine_content

This action hides the reported content and does not remove the report. A typical use-case is when a content needs to be hidden while the decision is made whether it’s violating or not. The content can later be restored via the restore action.

Restore the reported content

POST /{report-id}/unquarantine_content

This action restores content that has been hidden via the hide action (A3) and does not remove the report.

Reading Content Reports Statistics

Read the number of actioned reports

GET /community/reported_content?
  summary=allowed_content_count.days(30),
          deleted_content_count.days(30)

Both allowed_content_count and deleted_content_count are parameterized fields and you should pass the aggregation window size in days.

Webhooks

The Reported Content API also supports webhooks for related topics and fields, following the Workplace webhook conventions.

These webhooks follow the same conventions in terms of data shapes as the above. Please refer to the Workplace Webhook reference for details relating to payload format. Webhooks allow subscription to changes in a field set on a specific topic.

Note that webhook fields do not represent entity fields.

• Topic: Content Report

  • Field: reported_content - called when a Workplace user reports a content.

Example webhook body for content report

Below is an illustration of the body for a content report web hook notification.

{
  "object":"reported_content",
  "entry":[
    {
      "id":"{report_id}",
    }
    , ...
  ]
}
    

Related Permissions

While this document is predominantly related to reported content related features which use the read_and_action_reported_content permission granted during app review, there are a number of other feature permissions that are likely to be needed to create fully-featured integrations.

• Read group content: to read and action reported content in groups
• Read user timeline: to read and action reported content posted on users’ timelines
• Read Knowledge Library content: to read and action reported Knowledge Library content
• Manage group content: to action reported content in groups
• Manage user timeline: to action reported content posted on users’ timelines
• Manage work profiles: to action reported users