### Call API Step Usage Example

Source: https://github.com/thapaliyabikendra/dynamic-api-clients/blob/main/steps/CallApiStep.md

An example demonstrating how to configure the Call API Step within a workflow, showing two sequential API calls with input mapping and output extraction.

```json
{
    "Steps": [
    {
      "Id": "GetPMUserId",
      "StepType": "Amnil.AccessControlManagementSystem.Workflows.Steps.CallApiStep, Amnil.AccessControlManagementSystem.Application",
      "NextStepId": "RoleChangeAPICreate",
      "Inputs": {
        "ApiRequest": {
          "@email": "data[\"currentUserDetail\"].Email"
        },
        "ApiClientName": "\"GET_PM_USERS_API\""
      },
      "Outputs": {
        "pmUserId": "step.Response[\"data\"]"
      }
    },
    {
      "Id": "RoleChangeAPICreate",
      "StepType": "Amnil.AccessControlManagementSystem.Workflows.Steps.CallApiStep, Amnil.AccessControlManagementSystem.Application",
      "Inputs": {
        "ApiRequest": {
          "@userId": "data[\"pmUserId\"].processMakerUid",
          "@processId": "data[\"applicationDetails\"].processId",
          "@taskId": "data[\"applicationWorkflowInstanceId\"]",
          "@workflowId": "data[\"applicationWorkflowInstanceId\"]",
          "@employeeId": "data[\"operationFormData\"].userAccountForm.userAccountDetails.employeeId",
          "@employeeName": "data[\"operationFormData\"].userAccountForm.userAccountDetails.userAccountName",
          "@currentfunctionalTitle": "data[\"operationFormData\"].userAccountForm.userAccountDetails.currentfunctionalTitle",
          "@newFunctionalTitle": "data[\"operationFormData\"].roleChangeOperationForm.newfunctionalTitle",
          "@roleChange": "data[\"applicationDetails\"]"
        },
        "ApiClientName": "\"ROLE_CHANGE_API_CREATE\"",
        "CurrentUserDetail": "data[\"currentUserDetail\"]"
      },
      "Outputs": {
        "appUid": "step.Response[\"appUid\"]",
        "appNumber": "step.Response[\"appNumber\"]"
      }
    }
    ]
}
```

--------------------------------

### Recommended API Client Naming Patterns

Source: https://github.com/thapaliyabikendra/dynamic-api-clients/blob/main/ApiNamingConvention.md

Illustrates recommended naming conventions for API clients, emphasizing clarity, system context, precise actions, and target attributes. These examples guide developers towards creating understandable and maintainable API names.

```markdown
API Client Name                               | Strength                             
-----------------------------------------------|--------------------------------------
`NOCODB_MBL_HRMS_GET_EMPLOYEES_BY_DEPARTMENT` | Clear system context & filter        
`NOCODB_MBL_FINACLE_UPDATE_BRANCH_STATUS`     | Precise action and target attribute  
```

--------------------------------

### Action-Specific Naming Patterns

Source: https://github.com/thapaliyabikendra/dynamic-api-clients/blob/main/ApiNamingConvention.md

Details naming conventions for common API actions like retrieval (GET) and creation (POST), specifying the format and providing examples for each.

```APIDOC
Retrieval Operations (GET):
  Format: [PREFIX]_GET_[RESOURCE]_[QUALIFIER]
  Examples:
    NOCODB_MBL_HRMS_GET_EMPLOYEES_ACTIVE
    NOCODB_NMB_FINACLE_GET_BRANCHES_BY_REGION

Creation Operations (POST):
  Format: [PREFIX]_CREATE_[RESOURCE]
  Examples:
    NOCODB_MBL_HRMS_CREATE_EMPLOYEE
    NOCODB_MBL_CREATE_DEPARTMENT
```

--------------------------------

### API Client Naming Examples

Source: https://github.com/thapaliyabikendra/dynamic-api-clients/blob/main/ApiNamingConvention.md

Illustrative examples of API client names based on the defined standards, covering different sources, clients, systems, and actions to demonstrate practical application.

```APIDOC
Client Prefixes:
  MBL_: Machhapuchchhre Bank Limited
  NMB_: NMB Bank

System Prefixes:
  FINACLE_: MBL, NMB - Branches, accounts, customers
  HRMS_: MBL, NMB - Employees, departments, roles
  LDAP_: MBL, NMB - Users, authentication

Implementation Examples:
  NOCODB_MBL_GET_DEPARTMENTS
    - Use Case: Bank-wide department retrieval
  NOCODB_MBL_HRMS_GET_EMPLOYEES
    - Use Case: Employee data from HR system
  NOCODB_MBL_FINACLE_GET_BRANCHES
    - Use Case: Branch data from core banking system
  NMB_LDAP_GET_USER_ROLES
    - Use Case: User roles from directory service
```

--------------------------------

### Example 1: Simple User Profile Mapping

Source: https://github.com/thapaliyabikendra/dynamic-api-clients/blob/main/Samples/BasicJsonMapping.md

Maps basic user profile information from a source JSON to a new structure. Demonstrates direct value assignment and source path mapping for simple fields.

```json
// Source JSON:
{
  "userData": {
    "firstName": "John",
    "lastName": "Doe", 
    "contactInfo": {
      "email": "john.doe@example.com",
      "phone": "+1-555-0123"
    }
  },
  "accountStatus": "active"
}

// Mapping Rules:
{
  "fullName": { "source": "userData.firstName" },
  "email": { "source": "userData.contactInfo.email" },
  "phone": { "source": "userData.contactInfo.phone" },
  "status": { "source": "accountStatus" },
  "createdAt": "2024-01-15"
}

// Result:
{
  "fullName": "John",
  "email": "john.doe@example.com", 
  "phone": "+1-555-0123",
  "status": "active",
  "createdAt": "2024-01-15"
}
```

--------------------------------

### Resource Renaming Samples for Legacy Migration

Source: https://github.com/thapaliyabikendra/dynamic-api-clients/blob/main/ApiNamingConvention.md

Provides concrete examples of renaming legacy API resources to modern standards. This includes mapping old names like 'EMP_DATA' to 'MBL_HRMS_GET_EMPLOYEE' for better clarity and consistency.

```markdown
Resource     | Legacy Name         | Modernized Name               
------------|---------------------|-------------------------------
Employee     | `EMP_DATA`          | `MBL_HRMS_GET_EMPLOYEE`       
Department   | `DEPT_TREE`         | `MBL_GET_DEPARTMENT_HIERARCHY`
Branch       | `BRANCH_LOCATIONS`  | `MBL_FINACLE_GET_BRANCHES_MAP`
```

--------------------------------

### Example 3: Nested Object Creation Mapping

Source: https://github.com/thapaliyabikendra/dynamic-api-clients/blob/main/Samples/BasicJsonMapping.md

Creates a nested object structure in the destination JSON by mapping source fields to different levels. Shows how to organize related data into sub-objects.

```json
// Source JSON:
{
  "firstName": "Jane",
  "lastName": "Smith",
  "email": "jane@example.com",
  "age": 30,
  "city": "New York"
}

// Mapping Rules:
{
  "user": {
    "personal": {
      "name": { "source": "firstName" },
      "surname": { "source": "lastName" },
      "age": { "source": "age" }
    },
    "contact": {
      "email": { "source": "email" },
      "location": { "source": "city" }
    }
  }
}

// Result:
{
  "user": {
    "personal": {
      "name": "Jane",
      "surname": "Smith", 
      "age": 30
    },
    "contact": {
      "email": "jane@example.com",
      "location": "New York"
    }
  }
}
```

--------------------------------

### Example 2: Array Element Access Mapping

Source: https://github.com/thapaliyabikendra/dynamic-api-clients/blob/main/Samples/BasicJsonMapping.md

Maps specific elements from an array within the source JSON to destination fields. Demonstrates using array indexing to extract data from lists of objects.

```json
// Source JSON:
{
  "products": [
    {
      "id": 1,
      "name": "Laptop",
      "price": 999.99
    },
    {
      "id": 2, 
      "name": "Mouse",
      "price": 29.99
    }
  ]
}

// Mapping Rules:
{
  "firstProductId": { "source": "products[0].id" },
  "firstProductName": { "source": "products[0].name" },
  "secondProductPrice": { "source": "products[1].price" }
}

// Result:
{
  "firstProductId": 1,
  "firstProductName": "Laptop",
  "secondProductPrice": 29.99
}
```

--------------------------------

### Rules Engine Integration Configuration

Source: https://github.com/thapaliyabikendra/dynamic-api-clients/blob/main/README.md

Integrates with a rules engine to determine a value based on predefined rules. This example shows setting an 'isEligible' field by evaluating 'applicationData' against 'LOAN_ELIGIBILITY_RULES'.

```JSON
{
  "body": {
    "isEligible": {
      "source": "applicationData",
      "rulesEngine": "LOAN_ELIGIBILITY_RULES"
    }
  }
}
```

--------------------------------

### Complex Array Concatenation Transformation

Source: https://github.com/thapaliyabikendra/dynamic-api-clients/blob/main/README.md

Concatenates multiple arrays from different sources into a single array, using a specified separator. This example combines active, pending, and inactive user lists.

```JSON
{
  "combinedData": {
    "source": ["users.active", "users.pending", "users.inactive"],
    "transform": "concat",
    "separator": ","
  }
}
```

--------------------------------

### API Best Practices

Source: https://github.com/thapaliyabikendra/dynamic-api-clients/blob/main/README.md

Outlines best practices for API client configuration, covering credential management, performance optimization, security considerations, configuration organization, and error handling strategies.

```APIDOC
Best Practices:

1. Credential Management:
   - Use uppercase for credential system names (e.g., 'PAYMENT_API_KEY').
   - Implement credential rotation without changing configurations.
   - Store sensitive data encrypted in the credential store.

2. Performance Optimization:
   - Avoid deep nesting beyond 5 levels.
   - Use 'resultType: "First"' when only needing one item from arrays.
   - Cache OAuth tokens to minimize token requests.

3. Security Considerations:
   - Always use HTTPS for external APIs.
   - Implement request signing for sensitive operations.
   - Use appropriate authentication method for each API.
   - Never log decrypted credentials or tokens.

4. Configuration Organization:
   - Group related mappings together.
   - Use consistent naming conventions.
   - Comment complex transformations.
   - Validate configurations before deployment.

5. Error Handling Strategy:
   - Define clear success/failure indicators.
   - Map specific error codes and messages.
   - Implement conditional data retrieval based on success status.
```

--------------------------------

### JsonMapperService Core Concepts

Source: https://github.com/thapaliyabikendra/dynamic-api-clients/blob/main/README.md

Explains how to navigate JSON structures using dot notation and defines the structure of mapping rules for the JsonMapperService.

```APIDOC
Source Path Navigation:
  - Simple property: "propertyName"
  - Nested property: "parent.child.property"
  - Array element: "items[0].name"
  - Deep nesting: "data.results[2].details.info"

Mapping Rule Structure:
  Rules are JSON objects where:
  - Key: Destination property name
  - Value: Rule definition (constant, source mapping, or transformation)

  Example:
  {
    "destinationProperty": {
      "source": "sourceProperty",
      "transform": "transformationType"
    }
  }
```

--------------------------------

### Call API Step Parameters

Source: https://github.com/thapaliyabikendra/dynamic-api-clients/blob/main/steps/CallApiStep.md

Defines the inputs and outputs for the Call API Step. It specifies the request payload, the API client to use, and optional user details, along with the expected response structure.

```APIDOC
CallApiStep:
  Purpose: Makes HTTP requests to external APIs using a dynamic HTTP client service.
  Step Type: Amnil.AccessControlManagementSystem.Workflows.Steps.CallApiStep, Amnil.AccessControlManagementSystem.Application
  Parameters:
    Inputs:
      ApiRequest (JObject): The request payload to be sent to the API. Contains HTTP request details like URL, method, headers, body.
      ApiClientName (string): Name of the API client to be used. Must match a configured API client in the system.
      CurrentUserDetail (JObject, Optional): User data.
    Outputs:
      Response (JObject): Contains the API response after execution. Includes status code, headers, and response body.
```

--------------------------------

### Legacy API Migration Methodology

Source: https://github.com/thapaliyabikendra/dynamic-api-clients/blob/main/ApiNamingConvention.md

Outlines a phased approach for migrating legacy APIs to modernized naming conventions and endpoints. The methodology includes inventory audits, pattern mapping, and a three-phase deprecation strategy.

```markdown
1. **Inventory Audit**: Catalog existing APIs by resource type  
2. **Pattern Mapping**: Assign new names using convention rules  
3. **Phased Deprecation**:  
   - Phase 1: Dual support (legacy + new names)  
   - Phase 2: Redirect legacy to new endpoints  
   - Phase 3: Retire legacy endpoints  
```

--------------------------------

### Best Practice: Validate Source Structure

Source: https://github.com/thapaliyabikendra/dynamic-api-clients/blob/main/Samples/BasicJsonMapping.md

Suggests ensuring that source paths are valid and exist before attempting to map them, which can prevent unexpected null values or errors.

```json
// Mapping a confirmed path:
{
  "safeField": { "source": "confirmed.existing.path" }
}
```

--------------------------------

### API Description Template

Source: https://github.com/thapaliyabikendra/dynamic-api-clients/blob/main/ApiNamingConvention.md

Provides a structured template for writing descriptive API names. It follows a pattern that clearly indicates the source, action, resource, system, client, and any qualifiers.

```markdown
[Source] [Action] [Resource] [via System] [for Client] [with Qualifier]
```

--------------------------------

### Best Practice: Handle Optional Fields

Source: https://github.com/thapaliyabikendra/dynamic-api-clients/blob/main/Samples/BasicJsonMapping.md

Advises planning for missing data in the source JSON by providing fallback values or handling potential nulls gracefully in the mapping rules.

```json
// Handling optional fields:
{
  "optionalField": { "source": "data.optional" },
  "fallbackValue": "default"
}
```

--------------------------------

### Configure Multi-Step Authentication Flow

Source: https://github.com/thapaliyabikendra/dynamic-api-clients/blob/main/README.md

This JSON configuration illustrates a multi-step authentication process. It defines sequential API calls, including obtaining a token via OAuth and then using that token in subsequent API requests, demonstrating how to manage dependent authentication steps.

```JSON
{
  "step1_getToken": {
    "url": "https://auth.api.com/token",
    "body": {
      "source": "ApiClientCredential OAUTH_CREDS"
    }
  },
  "step2_apiCall": {
    "url": "https://api.service.com/data",
    "headers": {
      "Authorization": "Bearer {tokenFromStep1}"
    }
  }
}
```

--------------------------------

### Standard API Client Naming Syntax

Source: https://github.com/thapaliyabikendra/dynamic-api-clients/blob/main/ApiNamingConvention.md

Defines the standard format for API client names, including optional system and qualifier elements, adhering to UPPER_SNAKE_CASE and specific rules for resource forms and element order.

```python
[SOURCE]_[CLIENT]_[SYSTEM]_[ACTION]_[RESOURCE]_[QUALIFIER]  # SYSTEM optional for client-level APIs
```

--------------------------------

### Simple Field Mapping Configuration

Source: https://github.com/thapaliyabikendra/dynamic-api-clients/blob/main/README.md

Demonstrates how to map fields from a source JSON to destination properties in the request body using the JsonMapperService.

```json
{
  "body": {
    "transactionId": {
      "source": "orderId"
    },
    "amount": {
      "source": "payment.totalAmount"
    }
  }
}
```

--------------------------------

### JSON Path Syntax: Array Indexing

Source: https://github.com/thapaliyabikendra/dynamic-api-clients/blob/main/Samples/BasicJsonMapping.md

Illustrates accessing elements within JSON arrays using square bracket notation with zero-based indices. Essential for mapping data from lists or arrays.

```json
// Accessing array elements:
"items[0]" → First item in items array
"users[2].name" → Name of third user
"data.results[0].id" → ID of first result
```

--------------------------------

### Resource Hierarchy Model Diagram

Source: https://github.com/thapaliyabikendra/dynamic-api-clients/blob/main/ApiNamingConvention.md

Visual representation of the API client naming hierarchy, illustrating the flow from data source to organizational client, system, action, and finally the resource.

```mermaid
graph TD
    A[Source<br><small>e.g. NOCODB, ACMS</small>] --> B[Client<br><small>e.g. MBL, NMB</small>]
    B --> C[System<br><small>e.g. FINACLE, HRMS</small>]
    C --> D[Action<br><small>e.g. GET, UPDATE</small>]
    D --> E[Resource<br><small>e.g. EMPLOYEE, BRANCH</small>]
```

--------------------------------

### Configure Dynamic URL Construction

Source: https://github.com/thapaliyabikendra/dynamic-api-clients/blob/main/README.md

This JSON configuration shows how to construct API URLs dynamically. It specifies a base URL template and defines parameters that will be substituted into the URL, typically sourced from application data, allowing for flexible endpoint targeting.

```JSON
{
  "url": "https://api.service.com/v2/customers/{customerId}/orders",
  "urlParameters": {
    "customerId": {
      "source": "customer.id"
    }
  }
}
```

--------------------------------

### Best Practice: Use Clear Field Names

Source: https://github.com/thapaliyabikendra/dynamic-api-clients/blob/main/Samples/BasicJsonMapping.md

Recommends using descriptive and unambiguous names for destination fields to improve code readability and maintainability.

```json
// Good:
{
  "customerEmail": { "source": "user.email" }  
}
// Avoid:
{
  "e": { "source": "user.email" }             
}
```

--------------------------------

### OAuth Token Exchange Configuration

Source: https://github.com/thapaliyabikendra/dynamic-api-clients/blob/main/README.md

Demonstrates the configuration for exchanging OAuth credentials to obtain an access token. It specifies the request details and how to map the response fields.

```json
{
  "requestConfig": {
    "url": "https://auth.provider.com/oauth/token",
    "httpMethod": "POST",
    "contentType": "application/x-www-form-urlencoded",
    "body": {
      "source": "ApiClientCredential OAUTH_CLIENT_CREDENTIALS"
    }
  },
  "responseConfig": {
    "accessToken": {
      "source": "access_token"
    },
    "tokenType": {
      "source": "token_type"
    },
    "expiresIn": {
      "source": "expires_in"
    },
    "scope": {
      "source": "scope"
    }
  }
}
```

--------------------------------

### OAuth Client Credentials Configuration

Source: https://github.com/thapaliyabikendra/dynamic-api-clients/blob/main/README.md

Shows how to configure OAuth Client Credentials by referencing a credential system name in the request body, injecting client details for token acquisition.

```json
{
  "body": {
    "source": "ApiClientCredential OAUTH_CREDENTIAL_NAME"
  }
}

Example:
{
  "body": {
    "source": "ApiClientCredential AZURE_AD_CLIENT_CREDENTIALS"
  }
}
```

--------------------------------

### Error Handling: Missing Source Paths

Source: https://github.com/thapaliyabikendra/dynamic-api-clients/blob/main/Samples/BasicJsonMapping.md

Illustrates the behavior when a specified source path does not exist in the input JSON. The corresponding destination field is set to null.

```json
// If "user.middleName" doesn't exist in source:
{
  "middleName": { "source": "user.middleName" }
}
// Results in: { "middleName": null }
```

--------------------------------

### JSON Path Syntax: Combined Paths

Source: https://github.com/thapaliyabikendra/dynamic-api-clients/blob/main/Samples/BasicJsonMapping.md

Shows how to combine dot notation and array indexing to navigate complex nested JSON structures. This allows precise selection of data from deeply nested objects and arrays.

```json
// Combining dot notation and array indexing:
"response.data.users[0].profile.email"
"orders[1].items[0].product.name"
```

--------------------------------

### API Client Naming Anti-Patterns

Source: https://github.com/thapaliyabikendra/dynamic-api-clients/blob/main/ApiNamingConvention.md

Highlights common anti-patterns in API client naming, such as missing hierarchy elements, lack of source identification, or missing action verbs. It provides corrected versions to demonstrate best practices.

```markdown
Flawed Name             | Issue                                  | Corrected Version               
------------------------|----------------------------------------|---------------------------------
`DEPT_API`              | Missing hierarchy elements             | `MBL_GET_DEPARTMENTS`           
`GET_ROLES`             | No client/source identification        | `MBL_ACMS_GET_ROLES`            
`MBL_HRMS_EMPLOYEE`     | Missing action verb                   | `MBL_HRMS_GET_EMPLOYEE`         
```

--------------------------------

### API Versioning Syntax

Source: https://github.com/thapaliyabikendra/dynamic-api-clients/blob/main/ApiNamingConvention.md

Specifies the standard syntax for versioning API clients. This convention is used to indicate breaking schema changes, major functionality shifts, or modifications to resource relationships.

```bash
[STANDARD_NAME]_V{MAJOR_VERSION}
```

--------------------------------

### API Error Handling Scenarios

Source: https://github.com/thapaliyabikendra/dynamic-api-clients/blob/main/README.md

Describes common error scenarios encountered when interacting with APIs, including missing or inactive credentials, invalid paths, and transformation errors.

```APIDOC
Error Handling Scenarios:

1. Missing Credentials:
   - API Key: Sets empty string in header.
   - Basic Auth: Sets empty string in Authorization header.
   - OAuth: Returns empty Bearer token.

2. Inactive Credentials:
   - The service checks the 'IsActive' flag and returns empty values for inactive credentials.

3. Invalid Paths:
   - Simple mappings: The property is not included in the output.
   - Array mappings: Returns an empty array.
   - Nested objects: Creates an empty object structure.

4. Transformation Errors:
   - Invalid cast operations: Returns the original value.
   - Missing transformation parameters: Uses defaults (e.g., space for concat separator).
   - Array operations on non-arrays: Returns an empty array.
```

--------------------------------

### Configure Payment Gateway Request and Response

Source: https://github.com/thapaliyabikendra/dynamic-api-clients/blob/main/README.md

Defines the configuration for integrating with a payment gateway API. It specifies request details like URL, method, headers, and a dynamic request body structure with transformations. It also outlines how to map and transform the API response for success status, transaction reference, and payment URL.

```json
{
  "requestConfig": {
    "url": "https://payment.gateway.com/api/v2/process",
    "httpMethod": "POST",
    "contentType": "application/json",
    "headers": {
      "Accept": "application/json",
      "x-api-key": "PAYMENT_GATEWAY_API_KEY",
      "x-merchant-id": "MERCHANT_12345"
    },
    "body": {
      "transactionId": {
        "source": "orderId"
      },
      "amount": {
        "source": "totalAmount",
        "transform": "cast",
        "castTo": "string"
      },
      "currency": "USD",
      "customer": {
        "email": {
          "source": "customerEmail",
          "transform": "lowercase"
        },
        "name": {
          "source": ["firstName", "lastName"],
          "transform": "concat",
          "separator": " "
        }
      },
      "items": {
        "source": "orderItems",
        "transform": "map",
        "item": {
          "sku": {
            "source": "productId"
          },
          "name": {
            "source": "productName"
          },
          "quantity": {
            "source": "qty"
          },
          "price": {
            "source": "unitPrice"
          }
        }
      }
    }
  },
  "responseConfig": {
    "success": {
      "source": "status",
      "transform": "cast",
      "castTo": "bool"
    },
    "transactionReference": {
      "source": "data.reference"
    },
    "message": {
      "source": "message"
    },
    "paymentUrl": {
      "source": "data.redirectUrl"
    }
  }
}
```

--------------------------------

### OAuth Bearer Token Authentication

Source: https://github.com/thapaliyabikendra/dynamic-api-clients/blob/main/README.md

Illustrates JSON configurations for OAuth Bearer Token authentication, supporting system names for external tokens or special keywords for current user tokens.

```json
{
  "headers": {
    "Authorization": "Bearer API_CLIENT_SYSTEM_NAME"
  }
}

Special Cases:
  - "Bearer CURRENT_USER_TOKEN"
  - "Bearer EXTERNAL_API_CLIENT"

Example:
{
  "headers": {
    "Authorization": "Bearer PAYMENT_SERVICE_OAUTH"
  }
}
```

--------------------------------

### Configure Staff Information API Request with Signature

Source: https://github.com/thapaliyabikendra/dynamic-api-clients/blob/main/README.md

Details the configuration for fetching staff information from an API. This includes setting up the request URL, method, authentication headers, and a complex request body that involves generating a signature and encoding data. The response mapping includes extracting employee details, branch, department, position, contact, and status information.

```json
{
  "requestConfig": {
    "url": "http://mblcmapi.iis/api/v1/connect",
    "httpMethod": "POST",
    "contentType": "application/json",
    "headers": {
      "Accept": "application/json",
      "Authorization": "Basic MBL_BASIC_AUTH_CREDENTIAL"
    },
    "body": {
      "FunctionName": "MBLStaffDetailInfo",
      "requestModel": {
        "encodeBase64": true,
        "generateSignature": true,
        "signaturePrivateKeySystemName": "MBL_PRIVATE_KEY",
        "TransactionId": {
          "source": "transactionId"
        },
        "BranchCode": {
          "source": "branchCode"
        },
        "IncludeInactive": false
      }
    }
  },
  "responseConfig": {
    "code": {
      "source": "Code"
    },
    "message": {
      "source": "Message"
    },
    "data": {
      "totalCount": {
        "source": "Data.totalCount"
      },
      "items": {
        "source": "Data.QueryResult",
        "transform": "map",
        "item": {
          "employeeId": {
            "source": "HREmployeeId"
          },
          "staffId": {
            "source": "StaffId"
          },
          "fullName": {
            "source": ["Title", "FirstName", "MiddleName", "LastName"],
            "transform": "concat",
            "separator": " "
          },
          "branch": {
            "id": {
              "source": "BranchId"
            },
            "name": {
              "source": "BranchName"
            },
            "code": {
              "source": "BranchCode"
            }
          },
          "department": {
            "id": {
              "source": "DepartmentId"
            },
            "name": {
              "source": "DepartmentName"
            },
            "code": {
              "source": "DepartmentCode"
            }
          },
          "position": {
            "title": {
              "source": "FunctionalTitle"
            },
            "designation": {
              "source": "Designation"
            },
            "level": {
              "source": "Level"
            }
          },
          "contact": {
            "email": {
              "source": "Email",
              "transform": "lowercase"
            },
            "mobile": {
              "source": "CIMobileNo"
            },
            "address": {
              "source": "Address"
            }
          },
          "status": {
            "isActive": {
              "source": "Status",
              "transform": "cast",
              "castTo": "bool"
            },
            "isRetired": {
              "source": "IsRetired"
            },
            "isResigned": {
              "source": "IsResigned"
            },
            "isHead": {
              "source": "IsHead"
            }
          },
          "dates": {
            "dateOfBirth": {
              "source": "DOBinAD"
            },
            "joiningDate": {
              "source": "JoiningDateEng"
            }
          }
        }
      }
    }
  }
}
```

--------------------------------

### Resource-Specific Description Patterns

Source: https://github.com/thapaliyabikendra/dynamic-api-clients/blob/main/ApiNamingConvention.md

Details specific naming patterns for common resources like Employee, Department, and Branch. These patterns help ensure clarity and consistency when describing operations related to these resources.

```markdown
Resource   | Pattern                                  
------------|------------------------------------------
Employee   | `[Action] employee(s) [status/context]` 
Department | `[Action] department(s) [hierarchy]`    
Branch     | `[Action] branch(es) [location/status]` 
```

--------------------------------

### Basic Authentication Configuration

Source: https://github.com/thapaliyabikendra/dynamic-api-clients/blob/main/README.md

Describes the JSON structure for Basic Authentication, using a credential system name to inject Base64 encoded username:password into the Authorization header.

```json
{
  "headers": {
    "Authorization": "Basic CREDENTIAL_SYSTEM_NAME"
  }
}

Example:
{
  "headers": {
    "Authorization": "Basic MBL_BASIC_AUTH_CREDENTIAL"
  }
}
```

--------------------------------

### API Key Authentication Configuration

Source: https://github.com/thapaliyabikendra/dynamic-api-clients/blob/main/README.md

Details the JSON configuration for API Key authentication, specifying how to set API keys in request headers. The service retrieves and decrypts credentials by system name.

```json
{
  "headers": {
    "x-api-key": "API_KEY_CREDENTIAL_SYSTEM_NAME"
  }
}

Example:
{
  "headers": {
    "x-api-key": "PAYMENT_GATEWAY_API_KEY"
  }
}
```

--------------------------------

### Simple Response Mapping Configuration

Source: https://github.com/thapaliyabikendra/dynamic-api-clients/blob/main/README.md

Configures a simple mapping for API responses, extracting specific fields like StatusCode and StatusMessage to create a simplified output structure with status and message fields.

```JSON
{
  "status": {
    "source": "StatusCode"
  },
  "message": {
    "source": "StatusMessage"
  },
  "transactionId": {
    "source": "Data.TransactionReference"
  }
}
```

--------------------------------

### Complex Data Transformation for Analytics API

Source: https://github.com/thapaliyabikendra/dynamic-api-clients/blob/main/README.md

Illustrates a complex data transformation configuration for an analytics API. It includes setting headers, mapping nested request bodies with transformations, and structuring complex response data.

```json
{
  "requestConfig": {
    "url": "https://api.analytics.com/v1/report",
    "httpMethod": "POST",
    "headers": {
      "Authorization": "Bearer ANALYTICS_API_TOKEN"
    },
    "body": {
      "reportType": "SALES_ANALYSIS",
      "dateRange": {
        "from": {
          "source": "startDate"
        },
        "to": {
          "source": "endDate"
        }
      },
      "filters": {
        "branches": {
          "source": "selectedBranches",
          "transform": "map",
          "item": {
            "code": {
              "source": "branchCode",
              "transform": "uppercase"
            },
            "includeSubBranches": true
          }
        },
        "productCategories": {
          "source": ["electronics", "appliances", "furniture"]
        }
      },
      "userId": {
        "source": "currentUserDetail.id"
      }
    }
  },
  "responseConfig": {
    "summary": {
      "totalSales": {
        "source": "data.aggregate.totalRevenue",
        "transform": "cast",
        "castTo": "string"
      },
      "transactionCount": {
        "source": "data.aggregate.count"
      },
      "averageTicket": {
        "source": "data.aggregate.avgTicketSize"
      }
    },
    "topProducts": {
      "source": "data.products",
      "transform": "map",
      "resultType": "List",
      "item": {
        "productId": {
          "source": "id"
        },
        "productName": {
          "source": "name"
        },
        "sales": {
          "source": "revenue"
        },
        "rank": {
          "source": "rank"
        }
      }
    },
    "branchPerformance": {
      "source": "data.branches",
      "transform": "map",
      "item": {
        "branchCode": {
          "source": "code"
        },
        "branchName": {
          "source": "name"
        },
        "metrics": {
          "revenue": {
            "source": "totalRevenue"
          },
          "growth": {
            "source": "growthRate",
            "transform": "cast",
            "castTo": "string"
          },
          "target": {
            "achievement": {
              "source": "targetAchievement"
            },
            "status": {
              "source": "targetMet",
              "transform": "cast",
              "castTo": "bool"
            }
          }
        }
      }
    }
  }
}
```

--------------------------------

### Branch Operations APIs

Source: https://github.com/thapaliyabikendra/dynamic-api-clients/blob/main/ApiNamingConvention.md

Catalog of APIs for managing branch operations. Covers retrieving operational branches, onboarding new branches, and updating branch-specific information like operating hours.

```markdown
NOCODB_MBL_FINACLE_GET_BRANCHES_OPERATIONAL → Active banking locations
NOCODB_MBL_FINACLE_ADD_BRANCH               → New branch onboarding
NOCODB_MBL_FINACLE_UPDATE_BRANCH_HOURS      → Modify operating hours
```

--------------------------------

### Employee Management APIs

Source: https://github.com/thapaliyabikendra/dynamic-api-clients/blob/main/ApiNamingConvention.md

Catalog of APIs for managing employee data. Includes operations for retrieving active employees, creating new employee records, and updating employee roles or status.

```markdown
NOCODB_MBL_HRMS_GET_EMPLOYEES_ACTIVE       → All active employees
NOCODB_MBL_HRMS_CREATE_EMPLOYEE            → New employee registration
NOCODB_MBL_HRMS_UPDATE_EMPLOYEE_ROLE       → Modify employee positions
```

--------------------------------

### Signed Request Output Structure

Source: https://github.com/thapaliyabikendra/dynamic-api-clients/blob/main/README.md

Illustrates the expected output format for a processed API request after signature generation and encoding. It includes the Base64 encoded data, the generated RSA signature, and a timestamp.

```JSON
{
  "Data": "base64_encoded_request_model",
  "Signature": "rsa_signature",
  "TimeStamp": "2024-01-15T10:30:45.123"
}
```

--------------------------------

### JSON Path Syntax: Dot Notation

Source: https://github.com/thapaliyabikendra/dynamic-api-clients/blob/main/Samples/BasicJsonMapping.md

Demonstrates accessing nested properties within a JSON object using dot notation. This is fundamental for specifying source fields in mapping rules.

```json
// Accessing nested properties:
"user.name" → source.user.name
"profile.settings.theme" → source.profile.settings.theme
```

--------------------------------

### Request Model Configuration with Signature

Source: https://github.com/thapaliyabikendra/dynamic-api-clients/blob/main/README.md

Defines a request model structure for API requests, including options for Base64 encoding and RSA signature generation. It specifies how transaction ID and amount are sourced from input data.

```JSON
{
  "body": {
    "requestModel": {
      "encodeBase64": true,
      "generateSignature": true,
      "signaturePrivateKeySystemName": "MBL_PRIVATE_KEY",
      "TransactionId": {
        "source": "transactionId"
      },
      "Amount": {
        "source": "amount"
      }
    }
  }
}
```

--------------------------------

### Source Path Mapping in JSON

Source: https://github.com/thapaliyabikendra/dynamic-api-clients/blob/main/Samples/BasicJsonMapping.md

Copies values from a source JSON object to destination fields using dot notation paths. Supports accessing nested properties within the source structure.

```json
{
  "destinationField": {
    "source": "sourceField"
  },
  "userName": {
    "source": "user.profile.name"
  },
  "email": {
    "source": "contact.email"
  }
}
```

--------------------------------

### Current User Details Placeholder

Source: https://github.com/thapaliyabikendra/dynamic-api-clients/blob/main/README.md

Accesses current user information using special placeholders within the request model. It allows fetching details like ID, username, email, and full name.

```JSON
{
  "body": {
    "userId": {
      "source": "currentUserDetail.id"
    },
    "userName": {
      "source": "currentUserDetail.username"
    },
    "userEmail": {
      "source": "currentUserDetail.email"
    },
    "fullName": {
      "source": "currentUserDetail.fullname"
    }
  }
}
```

--------------------------------

### Nested Object Construction Configuration

Source: https://github.com/thapaliyabikendra/dynamic-api-clients/blob/main/README.md

Illustrates how to construct complex, nested JSON objects in the request body by mapping properties from various source locations.

```json
{
  "body": {
    "customer": {
      "personalInfo": {
        "firstName": {
          "source": "user.fname"
        },
        "lastName": {
          "source": "user.lname"
        }
      },
      "contact": {
        "email": {
          "source": "user.email"
        },
        "phone": {
          "source": "user.mobile"
        }
      }
    }
  }
}
```

--------------------------------

### Constant Values Configuration

Source: https://github.com/thapaliyabikendra/dynamic-api-clients/blob/main/README.md

Shows how to include static, constant values for properties in the request body configuration, independent of the source JSON.

```json
{
  "body": {
    "apiVersion": "v2",
    "channel": "WEB"
  }
}
```

--------------------------------

### Configure Conditional Mapping with Rules Engine

Source: https://github.com/thapaliyabikendra/dynamic-api-clients/blob/main/README.md

This JSON configuration defines how data fields are mapped based on rules defined in an external rules engine. It specifies the source of the data and the corresponding rules engine to use for processing, enabling flexible and dynamic data transformations.

```JSON
{
  "body": {
    "eligibilityStatus": {
      "source": "applicationData",
      "rulesEngine": "LOAN_ELIGIBILITY"
    },
    "riskCategory": {
      "source": "customerProfile",
      "rulesEngine": "RISK_ASSESSMENT"
    }
  }
}
```

--------------------------------

### Array Mapping Configuration

Source: https://github.com/thapaliyabikendra/dynamic-api-clients/blob/main/README.md

Details how to map arrays from a source JSON to a destination, including transforming individual items within the array using nested mapping rules.

```json
{
  "body": {
    "items": {
      "source": "orderItems",
      "transform": "map",
      "item": {
        "productId": {
          "source": "sku"
        },
        "quantity": {
          "source": "qty"
        },
        "price": {
          "source": "unitPrice"
        }
      }
    }
  }
}
```

--------------------------------

### Best Practice: Group Related Fields

Source: https://github.com/thapaliyabikendra/dynamic-api-clients/blob/main/Samples/BasicJsonMapping.md

Encourages organizing related data points into nested objects within the destination structure for better logical grouping and clarity.

```json
// Grouping related fields:
{
  "userInfo": {
    "name": { "source": "firstName" },
    "email": { "source": "email" }
  }
}
```

--------------------------------

### Cross-Resource APIs

Source: https://github.com/thapaliyabikendra/dynamic-api-clients/blob/main/ApiNamingConvention.md

Catalog of APIs that involve interactions between different resources. These include operations like assigning employees to branches or mapping positions within departments.

```markdown
NOCODB_MBL_GET_BRANCH_EMPLOYEES             → Staff assignments by location
NOCODB_MBL_GET_DEPARTMENT_ROLES             → Position mapping by unit
NOCODB_MBL_ASSIGN_EMPLOYEE_TO_BRANCH        → Staff transfer operations
```

--------------------------------

### API Error Handling Configuration

Source: https://github.com/thapaliyabikendra/dynamic-api-clients/blob/main/README.md

Defines the structure for handling API errors, specifying how to extract success status, error codes, and error messages from a response.

```json
{
  "responseConfig": {
    "success": {
      "source": "status",
      "transform": "cast",
      "castTo": "bool"
    },
    "errorCode": {
      "source": "error.code"
    },
    "errorMessage": {
      "source": "error.message"
    },
    "data": {
      "source": "data",
      "condition": "success == true"
    }
  }
}
```

--------------------------------

### Deletion Operations Naming Convention

Source: https://github.com/thapaliyabikendra/dynamic-api-clients/blob/main/ApiNamingConvention.md

Defines the standard naming convention for deletion operations. This format includes a prefix, the action type, the resource, and the specific method of deletion (e.g., soft or force).

```fix
Format: [PREFIX]_DELETE_[RESOURCE]_[METHOD]
```

--------------------------------

### Update Operations Naming Convention

Source: https://github.com/thapaliyabikendra/dynamic-api-clients/blob/main/ApiNamingConvention.md

Defines the standard naming convention for update operations within the API client naming scheme. It specifies a format that includes a prefix, the action type, the resource, and the attribute being updated.

```fix
Format: [PREFIX]_UPDATE_[RESOURCE]_[ATTRIBUTE]
```

--------------------------------

### String Lowercase Transformation

Source: https://github.com/thapaliyabikendra/dynamic-api-clients/blob/main/README.md

Applies a lowercase transformation to a specified field. This is useful for standardizing text data, such as email addresses.

```JSON
{
  "email": {
    "source": "Email",
    "transform": "lowercase"
  }
}
```

--------------------------------

### Direct Value Assignment in JSON Mapping

Source: https://github.com/thapaliyabikendra/dynamic-api-clients/blob/main/Samples/BasicJsonMapping.md

Assigns constant values directly to fields in the destination JSON object. Useful for setting default or static properties like version numbers or boolean flags.

```json
{
  "staticField": "constant value",
  "version": "1.0",
  "enabled": true,
  "maxRetries": 3
}
```

--------------------------------

### Array Response Mapping Configuration

Source: https://github.com/thapaliyabikendra/dynamic-api-clients/blob/main/README.md

Maps an array from a source response, including total count and transforming individual items. It extracts fields like ID, name, and department for each item in the array.

```JSON
{
  "data": {
    "totalCount": {
      "source": "Data.totalCount"
    },
    "items": {
      "source": "Data.QueryResult",
      "transform": "map",
      "item": {
        "id": {
          "source": "HREmployeeId"
        },
        "name": {
          "source": "EmployeeName"
        },
        "department": {
          "source": "DepartmentName"
        }
      }
    }
  }
}
```

--------------------------------

### String Uppercase Transformation

Source: https://github.com/thapaliyabikendra/dynamic-api-clients/blob/main/README.md

Applies an uppercase transformation to a specified field. This is useful for standardizing text data, such as country codes.

```JSON
{
  "countryCode": {
    "source": "country",
    "transform": "uppercase"
  }
}
```

--------------------------------

### Result Type Options for Array Mapping

Source: https://github.com/thapaliyabikendra/dynamic-api-clients/blob/main/README.md

Demonstrates mapping different result types (First, Last, List) from an array source. It applies a map transformation to extract an 'id' field from each item based on the specified result type.

```JSON
{
  "firstItem": {
    "source": "Data.Results",
    "transform": "map",
    "resultType": "First",
    "item": {
      "id": {
        "source": "Id"
      }
    }
  },
  "lastItem": {
    "source": "Data.Results",
    "transform": "map",
    "resultType": "Last",
    "item": {
      "id": {
        "source": "Id"
      }
    }
  },
  "allItems": {
    "source": "Data.Results",
    "transform": "map",
    "resultType": "List",
    "item": {
      "id": {
        "source": "Id"
      }
    }
  }
}
```

--------------------------------

### String Concatenation Transformation

Source: https://github.com/thapaliyabikendra/dynamic-api-clients/blob/main/README.md

Concatenates multiple string fields into a single string, using a specified separator. This is commonly used to create full names from first, middle, and last names.

```JSON
{
  "fullName": {
    "source": ["firstName", "middleName", "lastName"],
    "transform": "concat",
    "separator": " "
  }
}
```

--------------------------------

### String Multiple Replacements Transformation

Source: https://github.com/thapaliyabikendra/dynamic-api-clients/blob/main/README.md

Applies multiple string replacement operations sequentially. This is useful for cleaning text by replacing various special characters or HTML entities.

```JSON
{
  "cleanedText": {
    "source": "description",
    "transform": "replace",
    "replaceList": [
      { "from": "<br>", "to": "\n" },
      { "from": "&amp;", "to": "&" },
      { "from": "&lt;", "to": "<" }
    ]
  }
}
```

--------------------------------

### Error Handling: Invalid Array Indices

Source: https://github.com/thapaliyabikendra/dynamic-api-clients/blob/main/Samples/BasicJsonMapping.md

Describes the outcome when an array index is accessed that is out of bounds for the source array. The mapping results in a null value for that field.

```json
// If array has only 2 items (indices 0 and 1):
{
  "thirdItem": { "source": "items[2].name" }  
}
// Results in: { "thirdItem": null }
```

--------------------------------

### String Single Replacement Transformation

Source: https://github.com/thapaliyabikendra/dynamic-api-clients/blob/main/README.md

Performs a single string replacement operation, replacing all occurrences of a specified substring with another.

```JSON
{
  "formattedPhone": {
    "source": "phoneNumber",
    "transform": "replace",
    "replaceFrom": "-",
    "replaceTo": ""
  }
}
```

--------------------------------

### Type Casting Transformation (Boolean)

Source: https://github.com/thapaliyabikendra/dynamic-api-clients/blob/main/README.md

Casts a source field to a boolean type. Supports 'bool' or 'boolean' for true/false values.

```JSON
{
  "isActive": {
    "source": "Status",
    "transform": "cast",
    "castTo": "bool"
  }
}
```

--------------------------------

### Type Casting Transformation (Bit)

Source: https://github.com/thapaliyabikendra/dynamic-api-clients/blob/main/README.md

Casts a source field to a bit type, typically representing boolean values as 1 (true) or 0 (false).

```JSON
{
  "isFlagged": {
    "source": "FlagStatus",
    "transform": "cast",
    "castTo": "bit"
  }
}
```

--------------------------------

### Type Casting Transformation (Integer)

Source: https://github.com/thapaliyabikendra/dynamic-api-clients/blob/main/README.md

Casts a source field to an integer type. Supports 'int' or 'integer' for numerical values.

```JSON
{
  "statusCode": {
    "source": "ResponseCode",
    "transform": "cast",
    "castTo": "int"
  }
}
```

=== COMPLETE CONTENT === This response contains all available snippets from this library. No additional content exists. Do not make further requests.