You can record Silktide Analytics events from your backend server, for example if you wish to record downloads provided by a web server.
Unlike recording JavaScript events, this requires slightly more work to set up.
Identifying your API details
First you need to identify your Endpoint URL and Property key.
Endpoint URL
To find your Endpoint URL, open a webpage that uses your Silktide Analytics, then open the dev console in your browser. For example if you're using Chrome, select:
View
Developer
Developer Tools
Console
In the console, enter:
window.stConfig.endpointUrl
Your browser will respond with the URL of the endpoint, for example https://a.eu.silktide.com/v1/events. You should make a note of this.
If your browser instead returns an error, this page is not using the Silktide Analytics script.
Property key
Next, you will need to find your Property Key.
In the console, enter:
window.stConfig.propertyKey
The key returned is your Property Key, a 32-character string of numbers and letters. Keep a record of this, you’ll need it for the next step.
Making an API call
You should make an HTTP POST request to the Endpoint URL you identified above, passing the Property Key in the request.
Your request must have a Content-Type of application/json.
Example request format:
{
"propertyKey":"8bce2be8c07a84a70e7104634b42878b",
"url":"https://silktide.com/",
"ip":"84.14.132.114",
"viewWidth":979,
"userAgent":"Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/115.0.0.0 Safari/537.36",
"events":[
{
"event":"download",
"url":"https://example.com/downloaded-file.pdf"
}
]
}propertyKey, the Property Key, as identified aboveurl, the full URL of the current page. Note that if the URL does not belong to the specified Property, the event will be discarded.ip, the IP address of the visitor making the request. This is required to create a unique temporary identifier for the visitor. The IP address is never stored, will be anonymized, and only a non-reversible, short-term hash is retained by Silktide. If the IP address is blocked, for example because it comes from a known bot, the event will be discarded.viewWidth, the visitor's browser window view width.userAgent, the User Agent of the visitor making the request. This is used to identify the approximate browser and OS of the visitor, as well as to contribute towards their unique temporary identifier. The User Agent itself is never recorded.events, a list of Events and their properties. Each event must have aneventproperty containing the name of the event, other properties depend on the event type being recorded.
Troubleshooting Postman requests
If you are testing server-side events using Postman and receive a 202 Accepted response but the event does not appear in the Analytics events screen, check whether Postman is automatically sending its own User-Agent header.
In Postman, this header may be hidden by default. To view it, open the Headers tab and enable the hidden headers section.
For example, Postman may automatically add a header similar to:
User-Agent: PostmanRuntime/7.x
This HTTP header is separate from the userAgent field in the JSON payload. During testing, we found that requests containing Postman’s default User-Agent header could receive a successful 202 Accepted response, but the event would not appear in Analytics.
If you encounter this issue, try disabling Postman’s automatically generated User-Agent header or replacing it with a browser user agent string.
For example:
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36
If the event appears after disabling or replacing the header, the request was being accepted by the API but filtered during processing due to the HTTP User-Agent header.