API Call

1. Overview

The "API Call" action step allows users to execute HTTP REST calls using dynamic data obtained from views configured within Mitra. Each row generated in the view represents an API call, where variables configured in the body, headers, or URL are replaced with the corresponding values from the row. If no view is configured, a single call is executed without the use of variables.

2. Functionality

• Optional View Configuration: Users can configure a view (using SQL) to select the data they want to use in the API calls. Each column in the view becomes a variable available for the API call configuration. If no view is configured, the API call is made only once, without using variables.

• Variable Usage: Variables from the columns can be used in the body, headers, or URL of the API call using the format $variable_name, where variable_name corresponds to the lowercase column name in the view.

  • Example: For a column named ID_CLIENTE, the variable will be $id_cliente.

• Custom Body:

  • Enabled: Users can create a custom request body using the view's variables.

  • Disabled: A default body is automatically generated based on the fields and values returned by the view in JSON format.

• Execution: Each row in the view results in a separate API call, with variables replaced by the corresponding row values. If no view is configured, a single call is executed using either the default or custom body.

• Logging: All calls are logged in the INT_HTTP_REQUEST_LOG table, enabling users to track the status and results of each call.

3. Configuration Structure

3.1. Request Types

• GET: Retrieve information from an endpoint.

• POST: Create a new record at the endpoint.

• PUT: Update an existing record.

• DELETE: Remove an existing record.

3.2. URL

Provide the endpoint URL to be called. Example:

https:

3.3. Headers

Add necessary headers for authentication and request formatting. Example:

•   Content-Type: application/json

•   Authorization: Bearer $api_key

3.4. Body

Provide the request body in JSON format. Use the variables generated by the view to make the data dynamic.

• With Custom Body Enabled: Example:

{
  "customer_id": "$id_cliente",
  "name": "$nome_cliente",
  "email": "$email_cliente"
}

• Without Custom Body: The body is automatically generated based on the view’s returned data. For instance, if the view returns:

The body for each call will be:

{
  "id_cliente": "1",
  "nome_cliente": "João da Silva",
  "email_cliente": "joao@example.com"
}

{
  "id_cliente": "2",
  "nome_cliente": "Maria Souza",
  "email_cliente": "maria@example.com"
}

3.5. Available Variables

Once a view is configured, all its columns are available as variables, with their names converted to lowercase. Use the exact column names prefixed with $ in the configuration.

Example:

View SQL Configuration:

SELECT 
  ID AS ID_CLIENTE, 
  NAME AS NOME_CLIENTE, 
  EMAIL AS EMAIL_CLIENTE 
FROM 
  CUSTOMERS 
WHERE 
  STATUS = 'ACTIVE'

API Call Configuration:

• Request Type: POST

• URL: https://api.example.com/v1/customers

• Headers:

  • Content-Type: application/json

  • Authorization: Bearer $api_key

• Body (With Custom Body Enabled):

{
  "id": "$id_cliente",
  "name": "$nome_cliente",
  "email": "$email_cliente"
}

3.6. Request Logs

All request logs are stored in the INT_HTTP_REQUEST_LOG table, including:

• ID: Unique identifier for the log.

• DHREQUEST: Request date and time.

• DHRESPONSE: Response date and time.

• REQUESTBODY: Body of the request sent.

• RESPONSEBODY: Response body received.

• HTTPSTATUSCODE: HTTP status code returned.

• STATUS: Execution status (COMPLETED, ERROR).

4. Final Considerations

• Error Handling: Always check the status of the calls in the log table to identify potential errors and adjust configurations accordingly.

• Security: Protect API keys and other sensitive data. Configure appropriate permissions for accessing the views.