Using API

Amity APIs can be used either in Admin or User context. Regardless of whether you are using it as an admin or a user, you will need an access token before you can use the API.

Admin

For Administrators who are using our APIs in making server-to-server API calls, you need an Admin Access token to connect to the Amity server.

Refer to Admin API Access Token for the instructions on how to generate the admin access token.

User

If you want use the Amity Social Cloud APIs as a user, you need to register a session via Session API to retrieve the User Access token. Once you've received the accessToken, you can use the token to call other API endpoints. Please note that User Access token is subject to the same authorization as the owner of the access token.

Revoke User Access Token

User's access tokens can be revoked via the Revoke API. This API can only be used with an admin access token.

API Reference

Once you have the appropriate access token, you can now use the token to make API calls.

Our API documentation explains all API endpoints used in Amity Social Cloud. Refer to Amity API documentation for a list of all our Amity Social Cloud Rest APIs.​

To tweak the user experience for everyone on your network, you will need to use the Network Settings apis with an Admin Token. These services will enable you to toggle application controls such as:

• the ability to mention users

• showing all posts instead of only followed posts on the global feed

• user privacy modes

To see the full list of supported controls, consult the Network Settings section.

User last activity report helps network administrators view a user's activity by date and timestamp based on read and write actions of the users. This allows the administrator to identify active and inactive users.

Using this report, the administrator can also decide what action to take for these inactive users, such as hard deleting them or sending them a notification.

You need an admin account to generate the user's last activity report.

Generating the Report

Step 1: Register the session using the Admin account

POST '{{URL}}/admin/v1/login'
--form 'username="XYZ"' \
--form 'password="*****"'

Step 2: Get admin cookies

Step 3: Export the user last activity report

GET '{{URL}}/admin/v1/reports/user-last-activity' \
--header 'Cookie: {{Cookie}}'

Step 4: Get the list of user’s last activity report

Depending on the tool you use, you can either query it as a list or export it as a CSV report.

If you have any questions, please contact our technical support at support.asc@amity.co

Overview

Our Pre-Hook Event feature has been designed to offer customers increased control over user-generated content, community access, and the moderation of sensitive material. This enhancement not only provides a safer environment for applications but also empowers users to create custom moderation rules tailored to their specific requirements.

The Pre-Hook Event feature delivers a range of functionalities that users can employ to establish a more controlled environment within their applications. By enabling the Pre-Hook Event feature through network settings and adjusting the configuration parameters as needed, users can define custom rules and implement APIs to create custom use cases for enhanced moderation. This may include measures such as denying entrance to specific channels for certain users or modifying messages containing sensitive words before they are sent.

The system is designed to trigger pre-hook events for major available actions. Users can monitor the three response types provided by the APIs (allow, deny, and API timeout) and implement proper error handling measures to manage API error cases, ensuring a seamless user experience.

Configurations

To make the most of the Pre-Hook Event feature, follow these steps to implement it in your application:

1. Enable the Feature: Access your network settings through the pre-hook configuration API and enable the Pre-Hook Event feature. While doing so, adjust the configuration parameters, such as enabled, callbackUrl, and defaultAction, according to your requirements.

2. Create Custom Rules: Develop custom moderation rules based on your application's specific needs. These rules will help you address unique use cases and strengthen your moderation measures.

3. Implement APIs: Use the provided APIs to create custom use cases for enhanced moderation. These use cases can include denying entrance to specific channels for certain users, modifying messages containing sensitive words before they are sent, and more.

4. Monitor API Responses: Keep track of the three response types provided by the APIs: allow, deny, and API timeout. These responses will give you insight into the success or failure of your custom rules and actions. Here are the example of request and response of pre-hook event.

Request:

{
  "eventName": "message.shouldCreate",
  "data": {
    "key": "value"
  },
  "actor": {
    "_id": "string",
    "userId": "string"
  }
}

Response:

{
  "action": "allow",
  "data": {
    "key": "modified value"
  },
  "message": "string"
}

1. Error Handling: Ensure that you have a robust error handling mechanism in place to manage API error cases effectively. Proper error handling will contribute to a seamless user experience and prevent potential disruptions.

Implementation

The following sections explain the components, response handling, and error handling involved in the Pre-Hook Event feature.

Components

The external system's response must include the following components:

1. HTTP status code = 200

2. Response object with three possible scenarios:

   a. Allow the action without modification: { "action" : "allow" }

   b. Allow the action with modification: { "action" : "allow", "data" : { ... } // Modified data object }

   c. Deny the action: { "action" : "deny", "message" : "this is an error message" }

3. Signature key to ensure the security between the server and the client.

If a modified data object is returned, its data schema must match the original one.

Security

The security of the pre-hook events feature is ensured through the use of a signature key, which are crucial components in maintaining the confidentiality and integrity of the communication between the server and the client.

Secret Key

1. Upon configuring and enabling the pre-hook feature for the first time, a secret key is generated. This secret key is a randomly generated 16-byte hexadecimal string.

2. The secret key serves as a shared symmetric key between the server and the client, which is used for authentication purposes.

3. In case the secret key is leaked, it can be regenerated to maintain security.

4. Only network administrators are allowed to access and update the pre-hook setting and regenerate the secret key.

5. The secret key is available in the update setting API response only when enabling the feature for the first time or when regenerating the secret key. It is not available in the get setting API or when updating other fields.

Signature Key

1. The signature key is used to authenticate the payload on the external system.

2. It is computed using the HMAC Base64 digest of the request body. The HMAC Base64 digest is generated by performing the SHA-256 hash function with the secret key as the HMAC key, the request body as the payload, and digested as a Base64 string. Here's an example of generating a signature key from a secret key:

function genSignature(secretKey: string, payload: any): string {
  const hmac = crypto.createHmac('sha256', secretKey);
  hmac.update(JSON.stringify(payload));
  return hmac.digest('base64');
}

const payload = {
  eventName: 'message.shouldCreate',
  data: {
    ...
  },
  actor: {
    _id: 'privateId',
    userId: 'publicId'
  }
}
genSignature('secret', payload)

1. The signature key is included in the request header, ensuring secure communication between the server and the client.

2. To verify the signature key on the client side, they could do this by computing the hash with the above method and comparing it with the one in the request header. Here is an example

const signatureKey = req.headers['ASC-Signature-Key'];
const payload = req.body

const hmac = crypto.createHmac('sha256', secretKey);
hmac.update(JSON.stringify(payload));
const hash = hmac.digest('base64');

if (hash !== signatureKey) {
  throw new Error('Invalid signature!')
}

Example of an HTTP request with a signature key attached:

curl --location --request POST '<<CALLBACK_URL>>' \
--header 'ASC-Signature-Key: <<SIGNATURE_KEY>>' \
--header 'Content-Type: application/json' \
--data-raw '{
  "eventName": "channel.shouldCreate",
  "actor": {
    "_id": "63aab2059c25c70d98c32ecc",
    "userId": "sam"
  },
  "data": {
    "key": "value"
  }
}'

Response Handling

1. If the action is "allow", the system continues with the remaining application flow, using either the modified data payload (if provided) or the original payload.

2. If the action is "deny", the system returns an error to the caller with code 400000 as a BadRequestError:

   Copy

   {
     "errorCode" : 400000,
     "message" : "error message from deny action or BusinessError if null"
   }

Error Handling

In cases where the response object doesn't adhere to the specified format, or the request takes longer than 3 seconds, the system executes the following error handling flow:

1. Log the error with the endpoint URL, response status code, response object (trimmed to 300 characters length), or null if the request times out, and the error reason.

2. Use the default action (allow or deny) as configured in the setting. If the "deny" action is configured, the system returns an error to the caller with code 500401 as a BusinessError:

   Copy

   {
     "errorCode" : 500401,
     "message" : "error message from BusinessError due to external system error"
   }

If the pre-hook service is unavailable or unresponsive due to reaching maximum capacity or other internal server problems, the system executes the following error handling flow:

Use the default action (allow or deny) as configured in the setting. If the "deny" action is configured, the system returns an error to the caller with code 500000 as a BusinessError:

{
  "errorCode" : 500000,
  "message" : "error message from BusinessError due to internal error"
}

Once the pre-hook process is completed, the system logs the pre-hook URL, response action, and response duration.

Supported Events