You can configure your site to only allow content to be posted after an administrator approves it. There are two types of moderation: content and member. Both are explained in detail below.
Content Moderation
Content moderation applies to the following features:
There are three states for content and groups: pending, approved, and
deleted.
Note: Content cannot return to the pending state, it must be approved or
deleted.
Checking for Pending Content
By default both approved and unapproved items are returned in a list request,
you must specifically filter out the items you don’t want to see. To filter
out the unwanted content items, use the approved query parameter.
GET /2.0/BlogPost/recent?approved=false&fields=approved&count=10
The above request will return the ten most recent blog posts waiting to be
approved. In this case there is only one blog post waiting moderation. Notice
that the approved field is currently false:
{
"anchor": "b1XpktNQ5xHwLpHrdkcDn6dkyRdcgZR0",
"entry": [
{
"approved": false,
"author": "0fhpmsd4e9ep2",
"createdDate": "2013-04-12T21:46:11.771Z",
"id": "3011345:BlogPost:14144"
}
],
"firstPage": true,
"lastPage": true,
"resources": {},
"success": true
}
Approving Content
You can approve content by setting the approved field to true using a PUT request. In the example bellow the PUT request is made to the blog post endpoint. The body of the PUT request is shown on the second line.
PUT /BlogPost
id=3011345%3ABlogPost%3A14144&approved=true
If the member making the request is an administrator the server will respond with a success message:
{
"success": true
}
Once approved you cannot return to the pending state. If you want to remove the content, you must delete it. If you want to temporarily hide content from the rest of the site you can set the visibility field to me.
Rejecting Content
To reject content you must send a DELETE request with the ID of the content as a query parameter. You cannot send a PUT request to set the approved field to false. If you do, the server will respond with an error telling you to delete the content instead.
To delete a blog post with the ID 011345:BlogPost:14144, the request would look like:
DELETE /BlogPost?id=3011345:BlogPost:14144
If the member making the request is an administrator the server will respond with a success message:
{
"success": true
}
Member Moderation
Member moderation is similar to content moderation. The only difference is the introduction of a banned member state.
When a member joins the site they are placed in the pending state until an administrator approves them. If they are approved, the member can start using the site. If they are rejected the member is deleted.
An approved member can leave the site in one of two ways: banning or deletion. A deleted member is completely removed from the system and may rejoin the site using the normal sign up flow.
A banned member has all of their content removed, but they remain in the system. If a banned member tries to join again, they receive a message letting them know that they are banned and cannot join again. An administrator can reinstate a banned member, however their content that was deleted when they were banned is not restored.
Check for pending members
By default both approved and unapproved members are returned in a list request, you must specifically filter out the members you don’t want to see. To filter out the unwanted members, use the approved query parameter.
GET /2.0/User/recent?approved=false&fields=approved&count=10
The above request will return the ten most recent pending members. In this case there is only one pending member. Notice that the approved field is currently false:
{
"anchor": "PLPJF2UPMmrHklgsMzQbzRoGpVGmeg8s",
"entry": [
{
"approved": false,
"author": "13y7imet0czgr",
"createdDate": "2011-04-12T23:51:28.759Z",
"id": "3011345:User:14232"
}
],
"firstPage": true,
"lastPage": true,
"resources": {},
"success": true
}
Note
I have included the approved field in the fields parameter to demonstrate that we received the correct result. This parameter is not necessary to make the approved filter function correctly.
Approve a Pending Member
To approve a pending member, set the approved property to true using a PUT request. In the example below, the member with the ID
3011345:User:14232 is approved. The second line represents the body of the
request:
PUT /User
id=3011345%3AUser%3A14232&approved=True
If the member making the request is an administrator the server will respond with a success message:
{
"success": true
}
Reject a Pending Member
To reject a pending member you must delete them by sending a DELETE request and specifying their ID. You cannot reject a member by setting the approved field to false. If you try, you will receive an error message. The following example rejects the member with the ID 3011345:User:14232.
DELETE /User?id=3011345%3AUser%3A14232
If the member making the request is an administrator the server will respond with a success message:
{
"success": true
}
Ban Existing Member
To ban an existing member, send a PUT request and set the isBlocked field to true. In the example bellow, the member with the ID 3011345:User:14232 is banned. The second line represents the body of the request:
PUT /User
isBlocked=True&id=3011345%3AUser%3A14232
If the member making the request is an administrator the server will respond with a success message:
{
"success": true
}
Reinstate a Banned Member
To reinstate a banned member, send a PUT request and set the isBlocked field to false. In the example bellow, the member with the ID
3011345:User:14232 is unbanned. The second line represents the body of the request:
PUT /User
isBlocked=False&id=3011345%3AUser%3A14232
If the member making the request is an administrator the server will respond with a success message:
{
"success": true
}