API-Based Automation practice questions

String variable

Why it fails: Using a standard String variable for passwords causes the value to be stored in plain text. This is a major security risk, as the password can be easily read in the logs, memory, or debugging watch windows. It fails to meet the minimum security standards required for handling authentication credentials in enterprise automation.

GenericValue variable

Why it fails: GenericValue is an untyped, flexible data container that does not provide any security features. It stores data as plain text strings, making it just as insecure as a standard String variable. It is not intended for managing sensitive data and should never be used for password handling in any automation project.

Array of Strings

Why it fails: An Array of Strings is a collection structure for holding multiple text values. It provides no encryption or security for the data stored within it. Like standard strings, the contents of the array are visible in memory and logs, making it entirely inappropriate for storing and passing sensitive passwords to an API.

Hardcode the client ID and client secret directly into the 'Header' property of the HTTP Request activity for every call.

Why it fails: Storing sensitive credentials directly within activity properties is a significant security risk. It violates best practices for secret management and makes credential rotation difficult. Furthermore, including credentials in headers for every request increases payload size and exposes secrets in logs or system traces if not properly masked.

Use an 'Invoke Code' activity to write a custom Python script that handles token requests and stores the token in a global text file.

Why it fails: Invoking external code for standard authentication tasks adds unnecessary complexity and maintenance overhead. Files stored on disk are prone to security vulnerabilities and race conditions in multi-bot environments. Native UiPath activities are optimized for performance, security, and integration with Orchestrator assets, which should always be prioritized over custom scripts.

Utilize the 'OAuthToken' authentication type within the HTTP Request activity, referencing credentials stored in Orchestrator Assets.

Why it fails: Configuring the HTTP Request activity to use the native OAuthToken authentication type, combined with Orchestrator Assets, ensures secure, centralized credential management. This approach automatically handles token acquisition, caching, and expiration, reducing the risk of token-related errors and ensuring compliance with enterprise security policies during automated API interaction.

Use the Deserialize XML activity to convert the response into an XML document and then use XPath queries.

Why it fails: Deserialize XML is designed for XML data, not JSON. Using it on a JSON response would fail or produce unexpected results. The scenario specifies a JSON array, so XML parsing is inappropriate and would not correctly extract the required data.

Use the Read CSV activity to parse the JSON array into a DataTable.

Why it fails: Read CSV is for comma-separated values, not JSON. JSON has a different structure and cannot be parsed by CSV activities. This approach would not work and is not a valid method for handling JSON responses in UiPath.

Use a While loop with a counter to manually parse the JSON string using string manipulation functions.

Why it fails: Manual string manipulation is error-prone and not recommended when built-in JSON parsing activities exist. It would be inefficient and likely fail with complex JSON structures. UiPath provides dedicated activities for JSON deserialization, making this approach unnecessary and unreliable.

Set the HTTP Request activity's Method to POST, Endpoint to the token URL, and use the 'Parameters' property to add 'grant_type', 'client_id', and 'client_secret'. Then, in subsequent requests, add a custom header 'Token: ' + access_token.

Why it fails: While POST is correct, using the Parameters property might send them as query parameters depending on configuration, which is insecure. The token should be sent as 'Authorization: Bearer ' + access_token, not a custom 'Token' header. This configuration would likely fail authentication with standard OAuth 2.0 implementations.

Set the HTTP Request activity's Method to POST, Endpoint to the token URL, and use the 'Body' property with form-urlencoded format containing 'grant_type', 'client_id', and 'client_secret'. Then, in subsequent requests, add an Authorization header with value 'Basic ' + access_token.

Why it fails: The token retrieval part is correct if form-urlencoded is required, but using 'Basic' with the access token is wrong. Basic authentication is for username/password, not Bearer tokens. The correct scheme is 'Bearer'. This would cause authentication failures in subsequent API calls.

Set the HTTP Request activity's Method to GET, Endpoint to the token URL, and add query parameters for 'grant_type', 'client_id', and 'client_secret'. Then, use the token as a query parameter in subsequent requests.

Why it fails: OAuth 2.0 token endpoints typically require POST, not GET, for security and to prevent caching. Passing credentials in query parameters is insecure as they can be logged. Using the token as a query parameter is also discouraged; it should be in the Authorization header. This approach violates best practices and may not work with many APIs.

Use the 'Body' property to send the token as a form parameter, and set the 'Content-Type' to 'application/x-www-form-urlencoded'.

Why it fails: Sending a bearer token in the body is not standard for bearer authentication and may not be accepted by the API. The Authorization header is the correct location for bearer tokens. This approach also risks exposing the token in logs if the body is logged.

Add the token to the 'Headers' property as a string in the format 'Authorization: Bearer ' + token, and enable 'Secure' on the activity.

Why it fails: The HTTP Request activity does not have a 'Secure' property. While adding the token to headers is correct, there is no built-in secure flag on the activity. Instead, the token should be retrieved securely and passed as a variable, and logging should be controlled at the workflow level.

Use the 'Authentication' property of the HTTP Request activity, select 'Bearer', and provide the token variable. This automatically masks the token in logs.

Why it fails: The HTTP Request activity in UiPath does not have an 'Authentication' property with a 'Bearer' option. Authentication must be handled manually via headers. The activity does not automatically mask sensitive data; developers must ensure tokens are not logged by avoiding logging the token variable.

Use the Deserialize JSON activity to convert apiResponse into a JArray, then use the Select Token activity with the query "$.customers[0].email".

Why it fails: Deserializing into a JArray is incorrect because the root JSON is an object containing a customers array, not an array itself. Additionally, the query $.customers[0].email retrieves the email of the first customer regardless of status, which may not be 'active'. This approach fails to filter by status and misinterprets the JSON structure.

Use the Deserialize JSON activity to convert apiResponse into a JObject, then use a Select Token activity with the query "$.customers[?(@.status='active')].email" and take the first result.

Why it fails: The JSONPath filter syntax requires a double equals sign (==) for comparison, not a single equals sign. Using a single equals sign may cause the query to fail or return no results, depending on the JSONPath implementation. The correct filter is [?(@.status=='active')]. This subtle syntax error would prevent the automation from retrieving the email address.

Use the Deserialize JSON activity to convert apiResponse into a JObject, then use a For Each activity to iterate over the JObject properties and check each status value.

Why it fails: While iterating with For Each is possible, it is inefficient and error-prone for nested arrays. The JObject represents the root object, not the customers array directly. The developer would need to first access the customers array, then iterate. The Select Token activity with a JSONPath filter is more direct and reliable for this scenario.

Use the HTTP Request activity to POST to the API endpoint directly with the client ID and secret in the Authorization header using Basic authentication, bypassing the token endpoint.

Why it fails: While some APIs support Basic authentication, the scenario specifies OAuth 2.0 with client credentials grant. This grant requires exchanging credentials for an access token at the token endpoint. Sending client credentials directly to the API endpoint is not the OAuth 2.0 flow and will likely be rejected. The token endpoint must be called first.

Use the HTTP Request activity to GET the token endpoint with the client ID and secret as query parameters, then use the returned token in the Authorization header.

Why it fails: The OAuth 2.0 token endpoint requires a POST request, not GET. Sending credentials as query parameters is insecure and not supported by the client credentials grant. The token endpoint expects the client ID and secret in the request body, typically as application/x-www-form-urlencoded. Using GET would result in an error and fail to obtain a token.

Use the HTTP Request activity to POST to the token endpoint with the client ID and secret in the Authorization header using Basic authentication, then use the returned token in the body of subsequent requests.

Why it fails: The client credentials grant typically requires the client ID and secret in the request body, not in a Basic authentication header. While some implementations support Basic auth for client authentication, the standard approach is to send them as form parameters. Additionally, the access token must be included in the Authorization header as a Bearer token, not in the request body.

Use the Select Token activity directly on the response string to extract the required data.

Why it fails: The Select Token activity requires a JObject as input, not a raw JSON string. Attempting to use it directly on the response string will result in an error. The developer must first deserialize the JSON string into a JObject using the Deserialize JSON activity, then use Select Token. This option describes an incorrect order of operations.

Set the BodyFormat property to application/json to ensure the request body is sent as JSON.

Why it fails: Setting BodyFormat to application/json is necessary only when sending a JSON request body, such as in POST or PUT requests. The scenario does not specify that the request includes a body; it focuses on authentication and response parsing. While important for some calls, it is not one of the two required actions for this scenario.

Set the Accept header to application/xml to ensure the response is in a parsable format.

Why it fails: Setting the Accept header to application/xml would request an XML response, but the API returns JSON according to the scenario. This would be counterproductive and could cause the server to return an error or an unexpected format. The Accept header should be set to application/json if specified, but it is not one of the two required actions for authentication and parsing.

Invoke Workflow File

Why it fails: This activity is designed for modularizing UiPath projects by calling secondary XAML files. It lacks the network stack and protocol capabilities necessary to perform HTTP handshakes or communicate with remote REST endpoints. It does not handle headers, query parameters, or authentication payloads required for interacting with external web-based application programming interfaces.

Get Asset

Why it fails: The Get Asset activity is strictly for retrieving values stored within the Orchestrator database, such as keys or passwords. It does not possess the capacity to execute network requests, handle HTTP verbs, or process OAuth handshake sequences required by external REST APIs. It is meant for local platform resource management only.

Deserialize JSON

Why it fails: This activity is a data transformation tool used to parse raw JSON strings into usable objects within the UiPath runtime. It has no networking functionality and cannot initiate connections to external services. It is strictly used for processing the response body after a successful connection has already been established by another activity.

Always hardcode the API secret directly in the HTTP Request activity.

Why it fails: Hardcoding secrets in activity properties is a major security violation. It exposes credentials in plain text within the XAML files, which are often stored in source control systems. This practice risks unauthorized access to the production environment and violates standard information security policies required for enterprise automation deployments.

Store all API payloads in global variables only.

Why it fails: Using global variables for payloads creates naming collisions and memory management issues in complex workflows. It is better to use localized arguments and variables to ensure data isolation. This practice prevents accidental modification of data by unrelated processes running within the same workflow or sub-processes invoked during execution.

Disable SSL verification for all requests to ensure speed.

Why it fails: Disabling SSL verification creates a massive security vulnerability, allowing man-in-the-middle attacks. While it may solve connectivity issues temporarily, it removes the encryption layer that protects sensitive data transmission. Production environments must always maintain valid SSL/TLS handshakes to ensure the integrity and privacy of the communicated information.

Use 'Get Text' activity with 'data.id' as the selector.

Why it fails: Get Text is a UI Automation activity used for interacting with browser elements or desktop windows. It cannot parse or manipulate raw JSON response strings returned from web services. It requires a valid UI selector to function, which is not applicable when dealing with raw data structures like JSON objects.

Use 'Assign' activity to read the response string directly using string splitting.

Why it fails: String splitting is highly fragile and prone to errors if the JSON format changes slightly, such as whitespace variations or key ordering. It does not parse the underlying data structure correctly. Using formal JSON parsing activities ensures the automation remains resilient to minor formatting changes in the API response.

Use 'Deserialize JSON Array' to extract the 'id' field.

Why it fails: Deserialize JSON Array is specifically for parsing JSON structures that start with square brackets, indicating a list of items. Since the exhibit shows a JSON object starting with curly braces, this activity will throw an invalid cast exception during execution because it expects an array type instead of an object.

GET

Why it fails: GET is used exclusively for retrieving or reading data from an existing resource. It should not be used for creating, updating, or deleting records because it is designed to be idempotent and safe. Using GET for a creation request will likely result in the server ignoring the body data.

PUT

Why it fails: PUT is generally used for replacing or updating an existing resource entirely. While some APIs support PUT for creation, POST is the semantically correct and standard method for creating new resources. Using PUT for creation can lead to conflicts if the resource already exists or is not properly initialized.

DELETE

Why it fails: DELETE is strictly used for removing a resource from the server. Using it to create data will result in either an error or unintended consequences, such as an attempt to remove a resource that does not exist. It is completely inappropriate for any data submission or resource creation workflows.

Hardcoding credentials into the Endpoint field URL.

Why it fails: Embedding credentials in the URL is a severe security risk and is rarely supported by modern API standards. URLs are often logged in plain text, meaning anyone with access to the logs would see the secret. This practice is universally discouraged in favor of header-based or secure storage approaches.

Writing the password into a plain text file for the API to read.

Why it fails: APIs do not read local files from the machine executing the robot. The API request must contain the authentication information within the HTTP transmission itself. Using an external text file is not a supported authentication mechanism for REST web services and will result in a connection failure.

The API server is currently down or under maintenance.

Why it fails: Server downtime typically results in a 503 Service Unavailable or a 504 Gateway Timeout error. A 400 status specifically identifies the request itself as faulty, not the server's operational status. The issue lies within the request payload or formatting, rather than the server's ability to host the endpoint.

The authentication token has expired or is invalid.

Why it fails: Expired or invalid tokens result in a 401 Unauthorized or 403 Forbidden error. These codes signify that the server identifies the request source but rejects it based on permission settings. A 400 error focuses on the content of the request rather than the identity of the requester or their permissions.

The requested resource path does not exist on the server.

Why it fails: A non-existent resource path or endpoint typically returns a 404 Not Found error. 404 indicates that the URL is incorrect, whereas 400 indicates that the URL might be correct, but the information sent to that URL is somehow invalid or cannot be processed by the server-side logic.

The 'Timeout' property.

Why it fails: The Timeout property manages how long the robot waits for a response before terminating the connection. It has no impact on how the server interprets the data format of the request body. Modifying this value will not resolve issues related to incorrect content interpretation or server-side parsing failures.

The 'Accept' header.

Why it fails: The Accept header is used by the client to tell the server which response formats it can handle. While important for managing the response, it does not define the format of the data being sent in the request body. It has no bearing on the server's interpretation of the request payload.

The 'Authentication' property.

Why it fails: Authentication properties are strictly for verifying the identity of the client. They are completely unrelated to the data format of the body content. Changing these settings only affects the security handshake process and does not help the server understand the structure or type of the data being transmitted.

Deserialize JSON

Why it fails: Deserialize JSON is strictly for parsing data formatted as JSON. XML uses an entirely different syntax and node-based structure that this activity cannot understand. Attempting to use this activity on an XML string will result in a parsing error because it expects curly braces and key-value pairs, not XML tags.

Read Text File

Why it fails: Read Text File is a file system activity designed to read contents of local files on the disk. It does not perform any data transformation, parsing, or XML-specific navigation. It is entirely incapable of extracting data points from an API-provided string response, as it treats all inputs as plain text.

For Each Row

Why it fails: For Each Row is designed to iterate over DataTables or other collection objects. It cannot interpret XML hierarchies or perform node selection. It expects data to be in a tabular format, which XML is not inherently until it has been processed and converted by an XML-specific parsing activity first.

Write the first response to a CSV file and read it in the next step.

Why it fails: File I/O operations are significantly slower and introduce unnecessary disk latency into the automation. They also create potential issues with file locks or access permissions. Using memory-based variables for data passing is the standard, high-performance approach for API orchestration within a single workflow execution context.

Hardcode the ID into the second activity during development.

Why it fails: Hardcoding values prevents the automation from being dynamic. If the API returns a different ID each time, a hardcoded value will cause the second call to fail consistently. Automation must be data-driven, using variables to handle dynamic output from previous steps to ensure the process works for different scenarios.

Re-run the first request inside the second activity's scope.

Why it fails: Re-running requests is redundant and wasteful, increasing the processing time and potentially hitting API rate limits. It is poor practice to make the same call multiple times if the data is already available. The architecture should be optimized to fetch data once and reuse it throughout the remaining workflow steps.

API automation is easier for beginners because it requires no knowledge of JSON.

Why it fails: API automation strictly requires understanding JSON or XML structures, headers, and HTTP status codes. It is actually more technically demanding than basic UI recording. Misunderstanding the data structure or payload requirements will lead to immediate failure, making it unsuitable for beginners without prior knowledge of web service architecture and data formatting.

API automation allows for visual debugging of the application state.

Why it fails: API calls happen in the background and offer no visual representation of the application state. Debugging an API requires analyzing logs, response bodies, and HTTP status codes rather than watching a robot interact with a browser. It is inherently less visual than UI automation, which is better for real-time visual verification.

APIs are only available for web applications and never for desktop apps.

Why it fails: Many modern desktop applications expose REST or SOAP APIs to facilitate integration and data exchange. API-based automation is not restricted to web applications; it can be used for any system that provides a programmatic interface, regardless of whether it is a web service, desktop application, or backend server-side system.

Decrease the timeout value to 1000ms.

Why it fails: Decreasing the timeout will cause the robot to wait even less time for the server response, resulting in more frequent and guaranteed failures. This is the opposite of the required action for a process that is already timing out due to the server's slow processing speed during the API call.

Remove the timeout property entirely.

Why it fails: The Timeout property is mandatory in the HTTP Request activity and cannot be removed. Leaving it blank or trying to clear it will result in a validation error during workflow compilation. The property must always contain a positive integer value to define the maximum wait time for the network connection.

Switch the request to use the GET method instead.

Why it fails: Changing the HTTP verb does not influence the network timeout. A GET request can take just as long as a POST request depending on the server-side load and logic. Switching the method will not solve the issue of the process taking longer than the allotted time to receive a response.

The request failed due to a server-side error.

Why it fails: Status codes in the 5xx range indicate server-side failures. A 204 status code belongs to the 2xx success range, meaning the action was performed correctly by the server. It is not an error but an informative message about the response state, confirming the operation succeeded without returning payload data.

The request is unauthorized and needs a new token.

Why it fails: Unauthorized requests return a 401 status code. A 204 is a success code, indicating that the client's credentials were valid and the action was carried out. It does not indicate any issue with the authentication layer or the validity of the token used during the request process.

The API endpoint has been deprecated or removed.

Why it fails: If an endpoint is removed or invalid, the server will return a 404 Not Found error. A 204 status implies that the endpoint exists, was reached correctly, and the requested action was successfully executed by the server-side application logic, just without the return of a standard response data body.