Overview
The configuration of system actions or API endpoints utilising the ${SiteUrl} variable necessitates careful attention to the presence or absence of trailing slashes. The way these slashes are configured can influence how paths resolve, potentially leading to broken integrations if not addressed properly.
${SiteUrl} Behaviour Matrix
The following matrix illustrates various configuration scenarios for the Site URL input and the corresponding resolved outputs:
# | Configuration Scenario | Site URL Input | Action / Formula Path | Resolved Output | Status |
|---|---|---|---|---|---|
1 | Recommended Standard | https://some.system/contextPath | ${SiteUrl}/rest | https://some.system/contextPath/rest | 🟢 Success (Cleanest) |
2 | Legacy Alternative | https://some.system/contextPath/ | ${SiteUrl}rest | https://some.system/contextPath/rest | 🟡 Success (Supported) |
3 | Double-Slash Error | https://some.system/contextPath/ | ${SiteUrl}/rest | https://some.system/contextPath//rest | 🔴 Fails (404 Error) |
4 | Missing-Slash Error | https://some.system/contextPath | ${SiteUrl}rest | https://some.system/contextPathrest | 🔴 Fails (Malformed URL) |
⚠️ Important Notes for Configuration
For existing customers currently using Scenario 2 (with a trailing slash), it is crucial to note that copying and pasting standard template actions, which default to /rest, might result in a double-slash error as indicated in Scenario 3. For new setups, it is always recommended to use Scenario 1, which indicates no trailing slash in settings and a leading slash in your actions.
Conclusion
Understanding the configuration of the legacy ${SiteUrl} variable is essential to avoid issues with API endpoints and ensure proper functionality within the system. By adhering to the guidelines outlined in this article, you can secure successful integration and functionality.