Pass Dynamic Values
A linked service's URL and header values can contain {{params.x}} placeholders that are filled in when the service is called. This lets one service adapt to each request — carry a search term in the query string, or forward the signed-in user's token so your endpoint can authenticate them — without hard-coding the value in the configuration.
Where Placeholders Go
- In the URL — e.g.
https://api.example.com/search?q={{params.query}}. The value is
URL-encoded, so free text is safe to pass.
- In a header value — add a header under Headers whose value is a template, e.g. an
Authorization header with value Bearer {{params.token}}.
A placeholder is written {{params.<name>}}, where <name> is a simple identifier.
Where the Values Come From
Values are supplied from two places and merged — a per-call value overrides an init value with the same name:
- At initialization — for values that stay the same for the whole session (a user token, a
tenant id). Pass them to startAssistant:
skdwn.startAssistant({
assistantId: 'as-xxxxxxxx',
accessToken: 'your-key-or-token',
params: { token: yourUserToken }
});
- Per call — for values that depend on the moment (a search term, a selected id). Pass them as
the fourth argument of executeProxyRequest:
executeProxyRequest('search_api', null, callback, { query: userInput });
A single service can use both at once — a fixed {{params.token}} header and a per-call {{params.query}} in the URL.
params is not userInformation
params are used only to fill these placeholders — they are never sent to the model or recorded in analytics. Keep tokens and request values in params; use userInformation only for context about the visitor.
Example: Forward the User's Token
A common pattern is to let your own endpoint authenticate the user. Configure the service with:
- URL —
https://api.example.com/me/orders - Header — name
Authorization, valueBearer {{params.token}} - At init —
params: { token: <the token your backend issued the user> }
Your API receives a normal Authorization: Bearer … header and validates it, exactly as it would for any request. Because your endpoint validates the token, this is safe even though the value is supplied by the page: an invalid or someone else's token only grants whatever that token already allows.
Only forward a credential your endpoint verifies
A {{params}} value comes from the page, so it is trustworthy only when the receiving endpoint verifies it (a signed token it validates) or the value isn't sensitive (a search term). Never treat a raw id passed in params as proof of who the user is — validate a real credential instead.
Related Docs
- Authenticate requests — a stored server-side secret, the alternative to a forwarded value.
- Advanced customization — where
executeProxyRequestlives.