Can anyone clarify the exact argument structure for GetRESTProxy() in a Studio snippet? I keep hitting an INVALID_FUNCTION runtime error when attempting to pass the endpoint and headers as separate parameters instead of a single config object, and the docs are ambiguous on whether it expects a map or distinct values. Running Studio 2024.1 on CXone.
It depends, but generally… GetRESTProxy() in Studio requires a single configuration object, not separate arguments. The INVALID_FUNCTION error occurs because the runtime expects a map containing the HTTP method, URL, and headers. Passing distinct values breaks the signature validation. Here is the correct structure for a GET request:
var config = {
"method": "GET",
"url": "https://api.nice.incontact.com/...",
"headers": {
"Authorization": "Bearer " + token
}
};
var response = GetRESTProxy(config);
Ensure the url is fully qualified. The API does not resolve relative paths within the proxy call. Also, verify that the OAuth token in the headers is valid and scoped correctly for the target endpoint. If you are debugging, enable trace logging in the Studio snippet to inspect the exact payload sent to the proxy service.
Have you tried bypassing the Studio GetRESTProxy() wrapper entirely? That function is notoriously fragile regarding signature validation and often fails with INVALID_FUNCTION when the runtime environment expects a specific map structure that isn’t immediately obvious in the documentation. Since you are dealing with CXone and likely need this data for widget state or pre-chat logic, direct browser-based fetch is more reliable and transparent. You avoid the black-box serialization issues of the Studio runtime by handling the HTTP request directly in JavaScript.
Here is a standard fetch pattern that works consistently across modern browsers and avoids the Studio proxy constraints. Note that you must handle CORS if the target API does not support it, but for internal CXone endpoints or public data sources, this is the cleanest path.
const response = await fetch('https://api.nice.incontact.com/...', {
method: 'GET',
headers: {
'Authorization': 'Bearer YOUR_ACCESS_TOKEN',
'Content-Type': 'application/json'
}
});
if (!response.ok) {
throw new Error(`HTTP error! status: ${response.status}`);
}
const data = await response.json();
console.log('Fetched data:', data);
This approach gives you explicit control over headers and error handling without relying on the Studio engine’s internal proxy implementation. It also makes debugging significantly easier since you can inspect the raw network request in the browser dev tools. If you are injecting this into a custom widget, ensure your CSP allows the target domain. I use this pattern for all external API calls in my messenger deployments to avoid Studio runtime quirks. It is less “abstracted” but far more stable for production environments where consistent JSON parsing is critical.
Make sure you construct the config object as a single map variable before passing it to GetRESTProxy(), as the runtime signature strictly rejects separate arguments. Never rely on implicit object literal coercion in Studio snippets; explicit variable assignment prevents the INVALID_FUNCTION crash.
It depends, but generally… the INVALID_FUNCTION error is a signature mismatch, not a logic flaw. GetRESTProxy() strictly requires a single configuration object. Passing arguments separately breaks the runtime validation. You are likely splitting the method and URL into distinct parameters. The runtime expects a unified map. Construct the object explicitly before invocation. This aligns with the suggestion above but clarifies the exact structure. Do not rely on implicit coercion. Define the variable. Assign the properties. Pass the variable. This prevents the crash. The documentation is vague on the strict typing. The runtime is not. Use this pattern. It works. It is consistent. It avoids the error. Test it. Verify the response. Do not bypass the wrapper. It is designed for this. Use it correctly. The fix is simple. The syntax is rigid. Adapt to the constraint. Do not fight it. The code below demonstrates the correct approach.