RCS and WhatsApp Template Management Technical Evaluation

After analyzing the functional requirements, we have finalized the following technical approach, which has been reviewed and discussed in detail with developers Israr, Karan, and Jay. However, we have also identified certain technical issues related to the proposed approach after further analysis of the functionality requirements.

Proposed Technical Approach:

1. Key Generation to invoke API:

   1. Customers have to log in on Central and generate API Key in RCS Module.

   2. To invoke the API, API key will be included in headers for security and identity validation between customers and the system.

   3. API Key will have a maximum validity of 60 days.

   4. API keys can be regenerated and expired using the "New Key" option available in the UI. Each key is valid for a maximum of 60 days and will automatically expire and require regeneration after this period.

2. Direct Invocation by Customer:

   1. Instead of the Central Service managing the file transfers, the customer will directly invoke the Phonon’s RCS service as per the API documentation.

   2. Upon the successful template creation, the RCS service will notify the Central Service.

3. Post-Creation Actions: The Central Service will then handle any necessary database updates, and the template will become available for use.

Technical Challenges:

1. API Endpoint Accessibility:

   1. Problem: Implementing JSON through API calls is not feasible as the endpoints of the Kairos services are not publicly open. Authentication is required on the application side before invoking the API endpoints.

2. Authentication for Kairos APIs:

   1. Problem: If we accept requests at Kairos API endpoints, they are publicly accessible but do not have an authentication or authorization system (e.g., customer-facing API keys). These APIs need to be secured according to customer specifications.

3. File Uploading via API:

   1. Problem: The Kairos API only supports JSON as the request payload format and does not allow direct media uploads. To enable media uploads, we need to create an endpoint that accepts form-data content. This means that end-users will have to submit a form-based request instead of a JSON-based one, which may be less user-friendly, especially for non-technical users.

4. Test Module

   1. Problem:  Currently, our architecture requires sending notifications through flow execution. This approach mandates setting up flow and listeners in all accounts for testing purposes. This setup consumes significant resources, increases the risk of impacting production, demands extensive manpower, and raises the likelihood of operational errors

   2. Solution :
      To address this, testing notifications are sent by directly invoking the gateway Products, bypassing the need for flow execution during testing.

   3. Drawback: Direct invocation of the gateway products lacks flow detail documents, which has resulted in gaps in calculating these attempts in billing reports. To mitigate this, data must be explicitly fetched within the MBD module, which will require validation and confirmation from the MBD team.

Technical Process:

1. For templates that require media attachments, we need to create a form-data request body.

2. After the form is created, we will download the file from the request body and upload it to a privately accessible S3 bucket.

3. A public URL for the file will be generated and sent from the Central Service to the RCS service endpoint.

4. The RCS service will then download the file again, as it needs to send it as an attachment to the VI’s endpoint.

Identified Issues with the Current Approach:

File Management:  

The current process involves downloading and uploading the same file multiple times, leading to inefficient file management and unnecessary overhead.