Skip to main content
AndrewK
Helper ⭐️
February 18, 2026
Solved

Need help using the secure API connector to change usernames from community custom page

  • February 18, 2026
  • 13 replies
  • 236 views

Hi All,

 

I am working on a custom page that will allow users to update their username using the community API and a custom connector. The API Customer Communities API Documentation passes the new username as a path parameter, and I wasn’t sure how to handle that. The connector has a place to add query parameters.

https://api2-eu-west-1.insided.com/user/{id}/{field}/{value}

 

So, this is what I tried.

My widget code

async function updateUserField() {
// Hardcoded just for test
const id = 22;
const field = "username";
const rawValue = "UpdatedName";


const value = encodeURIComponent(rawValue);


const connectorExecuteUrl = "/widget-service/connectors/username-update/execute";

const res = await fetch(connectorExecuteUrl, {
method: "POST",
headers: { "Content-Type": "application/json" },
// Here is how I passed the fields to be used in the URL parameters
body: JSON.stringify({ id, field, value })
});

const text = await res.text();
console.log(text)
}

I get a 403 error. I based the widget code off a screenshot from the knowledge base article but also tried using the execute connector code from the connector page but get an error that says the window.WidgetServiceSDK is not a constructor.

So, to summarize, can anyone help with the following:

  1. I need to pass path parameters, not query parameters. How would I do that?
  2. In the screenshot the widget used fetch to call the connector is that ok or am I supposed to use the execute connector code?
  3. Let me know if I’m missing anything else.

Thanks!!

Best answer by marekkoszlak

Hi! Secure API Connectors don’t support dynamic path parameters. That’s intentional, as letting the browser supply arbitrary paths can create security issues (path probing, hitting endpoints the connector wasn’t meant to expose). For security and maintainability reasons, we’re also discouraging using the Community Admin API directly from custom widgets.

That said, we recognize the gap these Connector setups are trying to solve, and we’re actively exploring a more robust pattern for safe extensions in that area.

Many thanks for bringing this up! These kinds of posts really help us understand the limitations we need to work on.

13 replies

jvdc
Expert ⭐️
May 5, 2026

Hey ​@AndrewK have you managed to get a more simple connector to work? For example call some user data and display it in the community?

 

In your screenshot you're asking what the “execute connector” code is for. I understand it is for you to launch the connector so that the API call is made. I had tried this in the past for my tests and I had not managed to get it to work. Instead something like this worked for me, where xxxx is the ID of your connector:

<script>

(() => {

  fetch('/widget-service/connectors/xxxx/execute')

    .then(res => res.json())

    .then(data => {

CATCHING API DATA

    })

    .catch(err => console.error('error', err));

})();

</script>

AndrewK
AndrewKAuthor
Helper ⭐️
May 5, 2026

Hi ​@jvdc 

 

Yes, I got a simpler connector working thanks! The issue I couldn’t resolve with this one was passing the new username into the connector from the widget and then using it in an API call to update the username.

https://api2-eu-west-1.insided.com/user/id/username/{{value}} ← is a path parameter instead of a query parameter which the connector does support

 

Hi! Secure API Connectors don’t support dynamic path parameters. That’s intentional...

 

At the time it turned out that was not possible, but I thought you had managed to do something similar. After taking a closer look, I think it still is not possible. I accomplished what I wanted to do using an Azure function instead of the connector.

Andrew
marekkoszlak
Gainsight Employee ⭐️
Gainsight Employee ⭐️
May 13, 2026

Thanks for the update and happy to hear you got this working with Azure!

We're looking at ways to make connectors more capable, and handling use cases like this one is part of what we're exploring. Nothing to share in terms of timelines just yet, but it's definitely on the list.