Download Postman Collection

This page helps the integrator to obtains the JSON of the Postman collection which can be download and imported in Postman.

Create Workspace and import Collection

In Postman, access the Workspaces drop-down menu and click on Create Workspace

Fill out the details required and click Create Workspace Button.

Go to a browser window (preferable Chromium based), and open the below URL:

https://api.postman.com/collections/14010984-f369ccce-75ee-4dc4-8013-58f26929d717?access_key=PMAT-01GY0SP1WWH0QZ2JG74K1MXPB2

The webpage will show raw JSON content of the postman collection exposed via the above URL.

Follow the below steps to save this content to a JSON file:

  1. Select all the content on the webpage.

  2. Open a Notepad and paste the JSON content.

  3. Save As this file and use the extension [dot] JSON to save the file as a JSON file type.

  4. Choose the file name as per your requirement. e.g. collection

  5. In the end, you will have collection.json file.

Goto Postman and click on import button towards the top left of the screen inside the workspace created above.

In the box that appears, drag and drop the collection.json file created above.

Once imported, the collection will look something like below:

The collection is developed directly by Bhashini team and the same may change as per new changes that will be introduced over time.

Accessing Variables

The postman collection has automation done for easy understanding of the integrators. For the same, variables are defined on Collection level.

To access these variables, click the Collection Name and then click on Variables.

This will list down all the variables that are used as a part of different API calls. Details of each variables is given below:

These variables might change as and when new features will be avaiable as a part of different calls. The collection will have to be imported again to receive the updates.

  • ulca_url: ULCA Endpoint to send the Pipeline Config Call

  • user_id: ID to uniquely identify each integrator as defined here.

  • api_key: API Key as generated by the integrator for a specific application as described here.

  • pipeline_id: Pipeline ID obtained by the integrator either via discussion with Bhashini team, ULCA Web, or Pipeline Search Call

  • callback_url: URL that is obtained from the response of Pipeline Config Call as described here. This parameter is dynamically allocated with the value as discussed later in this page.

  • callback_url_feedback: Feedback URL that is obtained from the response of Pipeline Config Call as described here. This parameter is dynamically allocated with the value as discussed later in this page.

  • compute_call_authorization_key: This is a key parameter which is used for authorization of the Pipeline Compute Call and is obtained from the response of Pipeline Config Call as described here. This parameter is dynamically allocated with the value as discussed later in this page.

  • compute_call_authorization_value: This is the value of the key above used for authorization of the Pipeline Compute Call and is obtained from the response of Pipeline Config Call as described here. This parameter is dynamically allocated with the value as discussed later in this page.

  • asr_service_id: ASR Service ID is the service ID allocated if ASR task is requested by the integrator either in individual task or as a combination of tasks and is dynamically allocated either via running With Config Request or Without Config Request as described in Request Payload.

  • nmt_service_id: NMT Service ID is the service ID allocated if Translation task is requested by the integrator either in individual task or as a combination of tasks and is dynamically allocated either via running With Config Request or Without Config Request as described in Request Payload.

  • tts_service_id: TTS Service ID is the service ID allocated if TTS task is requested by the integrator either in individual task or as a combination of tasks and is dynamically allocated either via running With Config Request or Without Config Request as described in Request Payload.

  • source_language: Source Language takes in ISO 639 Series code of the source language. Integrator defines this language so that the automation scripts written in Postman find appropriate Service IDs and allocated the asr_service_id, nmt_service_id and tts_service_id.

  • target_language: Target Language takes in ISO 639 Series code of the target language. Integrator defines this language so that the automation scripts written in Postman find appropriate Service IDs and allocated the asr_service_id, nmt_service_id and tts_service_id.

  • base64: This is an exemplary base64 content which is used for demo purposes. It can be replaced by the integrator as per their requirements.

  • inference_input_payload: This variable will be allocated with a value automatically after execution of the Postman Tests associated with and successful execution of Compute Request ASR. This is the input payload that is sent for making the Compute Request ASR API call. This variable will be used in Feedback Submission API Call. This is used for demo of Feedback Submission for ASR only. If any other Compute API call is made, developer should use the same input payload used for that particular Compute API which is then to be used for feedback submission.

  • inference_output_payload: This variable will be allocated with a value automatically after execution of the Postman Tests associated with and successful execution of Compute Request ASR. This is the output/response payload that is received after making a successful Compute Request ASR API call. This variable will be used in Feedback Submission API Call. This is used for demo of Feedback Submission for ASR only. If any other Compute API call is made, developer should use the same output/response payload received for that particular Compute API which is then to be used for feedback submission.

  • suggested_inference_output_payload: This variable will have exact same structure as inference_output_payload along with the modified values. The concept is that developer is letting the sever know what should have been the response instead of what has currently being received. For ex. Developer send Compute Request NMT API call for doing a translation from English to Hindi. Developer receives a response which contains Hindi text somewhere in that response JSON, but the translated text is slightly incorrect. The incorrect part is corrected in the same place in the output response JSON and this new JSON (with edited and corrected Hindi text) is sent back to the server as a part of this variable.

Accessing Automation Scripts

The Automation Scripts are written for With Config Request and Without Config Request API calls so that appropriate collection variables as described above can be allocated.

Once the Integrator clicks either of the API Call mentioned above, Automation Scripts can be accessed in the Tests Tab of that API Call as shown below:

Accessing Individual Calls and Combination Calls

Each individual as well as combination of tasks can be accessed easily.

PreviousResponse PayloadNextAppendix

Last updated