The notification tray service is designed to automatically create and group notification records in a notification tray separated by user. The main function of this service is to provide the notification history for each user.

Here's an example of a simple notification tray that we have customized with this service. As shown in the picture, the Notification Tray contains a history of notifications displayed as rows of notification records. Each notification record contains details about a particular notification, including a list of the actors who performed the action, the action performed (verb) and the target of the action (target).

Concept

• A notification record consists of actors, a verb and a target - for example:

  • John Doe and 3 others commented on Sarah Janes's Post

    • Actors: John Doe and 3 other users

    • Verb: comment

    • Target: Sarah Jane's Post

• Notification Tray automatically groups events with the same verb and target together and aggregate list of actors into the same Notification Record.

• By default, the notification tray displays up to 10 notification records per page, sorted from newest to oldest, using the date of the last update as a reference. All notification records are stored for 90 days from the last update.

• Each notification record displays up to 3 actor names, sorted by the date of record activity, except for mentions. They won't be grouped but shown individually.

• ImageUrl of a notification record is the profile image of the latest actor who acts on the target.

• The notification record expires 90 days after the timestamp of the lastUpdate and is then deleted from Notification Tray after expiring.

• When a user leaves a community, the user's notification records are not updated with the target associated with the community. When the user rejoins a community, the notification records are updated again, but events that happen during the time the user left the community are not retroactively reflected in the record.

Scenarios

The following table shows supported scenarios and Tray Message that is recorded into Notification Record

Last Read & Has Read

The notification tray supports 2 reading levels as follows:

1. Last Read: Update the last read timestamp of the user. This is used to update the total unread count of notification records.

2. Has Read: Flag on each individual notification record that shows whether the user has explicitly read or click the notification record. This is represented as hasRead value inside each notification record JSON and can be used to display 'unread dot' on each notification record on Notification Tray.

Limitations

• When a user changes their display name, the actor's name in Tray Message is not updated.

• Notification Tray currently does not support

  • Post on user feed

  • Grouping mention into one record

• Customization of description is not supported. If customization / localization of notification records is needed we recommend constructing the message at the frontend as notification records already contain all the information needed.

Don't worry, Version 2 can still be used, but it won't support the mention feature. So, we highly recommend migrating to v3, and here is the list of changes needed to use Version 3!

Beta Features Disclaimer

Beta features are new features currently under active and early development phase that and are excluded from Amity's SLAs.

We test new features and products before releasing them in beta. However, beta features and products may contain bugs, vulnerabilities, performance issues, or other problems. To minimize risk, we recommends that customers test these beta features in a sandbox environment before gradually using them in production scenarios.

We may change, make fixes to, remove features from, add features to, or otherwise improve or modify beta features before removing their beta designation. Although we strive to keep all the APIs / SDKs unchanged and interrupted, we may occasionally issue breaking changes into Beta features.

We regularly moves features from beta to general availability. However, since beta features vary in complexity and success criteria, we makes no timeline guarantees.

Some Beta Features may be under Private Beta - which means that the features are not available to the public. You can submit your request here if you would like to enable a feature under Private Beta on your account.

Webhook Events is a great way you can extend and build custom functionalities on your own by receiving triggers from Amity Social Cloud. When enabled, events that happen within your Chat and Social SDK are forwarded to your system in real-time. By receiving these events you can build and extend your own functions such as

1. Storing those events to build your own analytic dashboard

2. Build custom message moderation or automatic banning system

3. Build custom search and personalization functionalities based on user activities forwarded to your analytic system.

A webhook can also be termed as a type of API that is driven by events rather than requests. Instead of one application making a request to another to receive a response, a webhook is a service that allows one program to send data to another as soon as a particular event takes place. Webhooks are sometimes referred to as “reverse APIs,” because communication is initiated by the application sending the data rather than the one receiving it.

To receive these events you will need to set up a Webhook system as detailed below.

Setup

When an event is triggered, an HTTP POST payload is sent to the Webhook's configured URL. Webhooks can serve various purposes such as creating push notifications, backup logging or even building external applications based on Webhook events.

• Admin users can create new Webhooks in admin panel by using URL

• Admin users can delete selected Webhooks in admin panel as well

• We recommend having no more than 10 Webhooks per network

• All Webhooks will be triggered near-real-time as the events occur. Please see#events for list of events available.

• To preserve system performance, all webhook HTTP requests will timeout in 1.5 seconds - please make sure your webhook receiver provide response back within the interval to prevent losing any requests.

• Upon receiving the webhook, the system should return with response status code of 200 with an empty JSON response.

Delivery Headers

The HTTP POST payloads that are delivered to your webhook's configured URL endpoint will contain the following headers:

Example Delivery

POST /your-webhook HTTP/1.1
x-amity-signature: <HMAC Base64 Digest>
User-Agent: node-superagent/4.0.0
Content-Type: application/json
Content-Length: 442
{
  "event": "channel.didCreate",
  "data": {
    "userIds": ["A"],
    "channel": {
      "isDistinct": false,
      "type": "standard",
      "metadata": {},
      "tags": [],
      "isMuted": false,
      "lastActivity": "2018-11-30T09:35:23.816Z",
      "updatedAt": "2018-11-30T09:35:23.815Z",
      "createdAt": "2018-11-30T09:35:23.815Z",
      "isRateLimited": false,
      "rateLimitWindow": 1000,
      "channelId": "testWebhook",
      "memberCount": 0,
      "messageCount": 0
    },
    "users": [
      {
        "displayName": "A",
        "updatedAt": "2018-11-30T11:39:19.615Z",
        "createdAt": "2018-11-01T09:33:57.811Z",
        "userId": "A",
        "roles": [],
        "flagCount": 0,
        "hashflag": { "bits": 0, "hashes": 0, "hash": [] }
      }
    ]
  }
}

Events

Once webhook is activated, you will start receiving events on a near-real-time basis. Please check our API Reference for full list of events and their payload.

Deprecation Notices

From 20 June 2022, we have deprecated the following legacy webhook events:

• message.created

• channel.created

• channel.joined

• channel.membersAdded

• v3.video-streaming.didRecord

• v3.video-streaming.didStart

• v3.video-streaming.didStop

As these webhook events were only accessible internally, this deprecation should have no impact on our current customers. For a list of events that we currently support, please refer to our API Reference.

Enhance moderation is a feature that allows all uploaded text, images, and videos on posts as well as text and images comments to be scanned and moderated for inappropriate, offensive, and unwanted content by using AI.

To this end, we've implemented AI Text moderation to detect and moderate text on posts and comments that contain

• Sexually explicit or adult in certain situations

• Sexually suggestive or mature in certain situations

• Offensive in certain situations.

And AI Image and Video moderation technology to detect and moderate images, and videos on posts as well as images on comments that contain

• Adult Toys

• Air crash

• Alcohol

• Alcoholic Beverages

• Bare-chested Male

• Corpses

• Drinking

• Drug Paraphernalia

• Drug Products

• Drug Use

• Drugs

• Emaciated Bodies

• Explicit Nudity

• Explosions and blasts

• Extremist

• Female Swimwear Or Underwear

• Gambling

• Graphic Female Nudity

• Graphic Male Nudity

• Graphic Violence Or Gore

• Hanging

• Hate Symbols

• Illustrated Explicit Nudity

• Male Swimwear Or Underwear

• Middle Finger

• Nazi Party

• Nudity

• Partial Nudity

• Physical Violence

• Pills

• Revealing Clothes

• Rude Gestures

• Self Injury

• Sexual Activity

• Sexual Situations

• Smoking

• Suggestive

• Tobacco

• Tobacco Products

• Violence

• Visually Disturbing

• Weapon Violence

• Weapons

• White Supremacy

Our enhance moderation solution empowers you to establish a secure online environment for your users, effortlessly eliminating the necessity for any human intervention. By harnessing the power of advanced AI technology that automatically scans and moderates all user-generated content, effectively identifying and addressing any inappropriate or offensive material. This proactive approach enables you to cultivate a welcoming and protected community for your users, without relying on manual oversight.

How does Enhance Moderation Work?

The Enhance AI moderation is performed using two main factors - flagConfidence and blockConfidence. When a post or a comment is successfully created, our AI system will automatically scans both the post's text and media, generating a confidence value as a result. If this confidence value falls below flagConfidence, the post/comment seamlessly passes the moderation without any issues. In cases where the confidence value falls between flagConfidence and blockConfidence, the Enhance moderation feature flags the post/comment for review. You have the option to review the flagged content within the Amity Console or listen to Amity real-time flag post event through your webhook on the server side, allowing you to implement appropriate actions based on your moderation policies. Finally, if the confidence value surpasses blockConfidence, the system deletes the post/comment altogether, ensuring a proactive approach to maintaining a safe online environment.

Enhance Moderation Description

Specify API Endpoint

To use the enhanced moderation APIs, specify the appropriate API endpoint on each HTTP request. Each data center has a unique endpoint, so it's essential to adjust it accordingly. By selecting the correct endpoint associated with the right location, you ensure faster response times and optimize the overall performance of your API requests.

Get Moderation Confidence Level

Get moderation confidence level API can be used to retrieve confidence level for each moderation category. The API will return list of moderation category along with the corresponding confidence level.

Update Moderation Confidence Level

Set moderation confidence level API can be used to set confidence level to any moderation category. The API will return list of moderation category along with the corresponding confidence level.

We recommend adjusting the confidence levels for each category based on your moderation policies and the needs of your community. By doing so, you can ensure that Enhance Moderation provides the optimal level of moderation for your platform.

Content Search allows you to perform more complex content searching and sorting. The feature can be used for the following use cases:

• Search post by text content

• Find posts that contain a specific hashtag

• Sort post by last activity or reaction count

Search Posts

Search Posts API can be used to search and sort relevant posts created into Amity Social. All APIs will return sorted list of post IDs that contains relevant contents.

API Reference

(V2) Search posts by query as indicated in request JSON body

POST https://beta.amity.services/search/v2/posts

Headers

Request Body

Query JSON

query is a JSON object that indicates the posts to be searched for. The following is the full JSON structure with all the fields:

All fields are optional. If targetId is present the system will search for posts on those communities. If targetId is not specified the system will search for all posts created by userId calling the API.

For Search V2:

targetType can be the following values:

• community - search posts in all communities ID as defined in targetId

• self - search all posts that belongs to the user passed in userId within request body

• public - search all posts that is in all public communities

Limitations

Current limitations on Search Posts API are

• Posts created on user feed is not yet searchable.

Query & Sort Format

NumberQuery

NumberQuery JSON structure defines range of numerical value to look for in a property. Available fields within the JSON structure are:

TimeQuery

TimeQuery JSON structure defines range of date time value to look for in a property. Available fields within the JSON structure are:

Sort JSON

sort is a JSON array that indicates how should the returning contents be sorted. The following is the full JSON structure:

Tracking user activity when users perform actions on posts or comments. The API tracks the following actions:

• Reactions to the post

• Comments to the post

• Reactions to the comment

• Replies to the comment

• Remove reactions or comments

API Reference

Retrieve activities of user's actions

GET https://beta.amity.services/user-activities

Query Parameters

Headers

Example curl

Scenario

The following table shows the supported scenarios and user actions that are recorded in the User Activity Record

The block/unblock user service is designed to support block/unblock users feature. The primary function of this service is to:

1. Block/Unblock other users

2. Check whether or not the system should hide the content of the specified user ID, based on block/unblock from

3. Get a list of users blocked by the current user

Block Other Users

With the Block API, you can add a user to the list of users to be blocked.

API Reference

POST https://beta.amity.services/block/members

Headers

Request Body

{
"status": "success"
}

Example curl

curl --location --request POST 'https://beta.amity.services/block/members' \
--header 'Authorization: Bearer <ACCESSTOKEN' \
--header 'Content-Type: application/json' \
--data-raw '{
    "blockUserId":"userId"
}'

Limitations

Current limitations of the block API are:

• Only 1 user can be blocked at a time.

• The Block API has no influence on the Amity Feed API. Developers must filter the blocked content themselves in the frontend.

Unblock Other Users

With the Unblock API, you can remove a user from the list of currently blocked users.

API Reference

DELETE https://beta.amity.services/block/members

Headers

Request Body

{
    // Response
}

Example curl

curl --location --request DELETE 'https://beta.amity.services/block/members' \
--header 'Authorization: Bearer <ACCESSTOKEN>' \
--header 'Content-Type: application/json' \
--data-raw '{
    "blockUserId":"testBlock"
}'

Limitations

The current limitations of the Unblock Posts API are:

• Only 1 user can be unblocked at a time.

• The blocking API does not affect the Amity feed API. Developers have to filter blocked content themselves on the frontend.

Block User List

With the Block user list API, you can retrieve the list of users who have been blocked by the current user.

API Reference

POST https://beta.amity.services/block

Headers

Request Body

{
    "results": [
        {
            "blocked_userId": "xxxx",
            "netid_uid": "xxxx"
        },
        {
            "blocked_userId": "xxxx",
            "netid_uid": "xxxx"
        }
    ],
    "paginationToken": {
        "netid_uid": "xxxx",
        "blocked_userId": "xxxx"
    }
}

Example curl

curl --location --request POST 'https://beta.amity.services/block' \
--header 'authorization: Bearer <ACCESSTOKEN>' \
--header 'Content-Type: application/json' \
--data-raw '{}'

Limitations

Current limitations on Unblock Posts API are:

• Each request returns only 20 posts.

• The block API does not affect the Amity feed API. Developers have to filter the blocked content themselves in the frontend.

Check Whether the Content Should be Hidden or Not

checkIsHide API can be used to Check wether contents from users should be hide or not.

API Reference

GET https://beta.amity.services/block/members

Query Parameters

Headers

{
    "user1": true,
    "user2": true,
    "user3": false
}

Example curl

curl --location --request GET 'https://beta.amity.services/block/members?checkList=userId1&checkList=userId2' \
--header 'Authorization: Bearer <ACCESSTOKEN>'

Limitations

The current limitations of the Unblock Posts API are:

• You can check a maximum of 20 users for each request.

• The Block API does not affect the Amity feed API. Developers have to filter the blocked content themselves in the frontend.