Purpose
This guide helps technical customers quickly identify integrations that may break as TrackVia tightens browser-origin access and removes cross-origin CORS support.
Because earlier versions of our API did not enforce these restrictions, some customers built custom web experiences hosted on their own domains that call the TrackVia API directly from the browser. With the new security controls in place, browsers may now block those requests and display CORS-related errors.
If your custom integration has stopped working and you are seeing errors related to CORS, this guide explains what changed and how to resolve it.
What Is Changing
Web browsers enforce a security policy called Cross-Origin Resource Sharing (CORS). This policy restricts browser-based applications from making requests to APIs hosted on a different domain unless the API explicitly allows it.
Previously, TrackVia’s API did not strictly enforce these restrictions. As a result, some browser-based integrations were able to make direct requests to the API from external domains.
To improve security, in the future the TrackVia API will block cross-origin browser requests from domains that are not explicitly permitted.
What Integrations are Impacted
Custom integrations with TrackVia that:
- Run in a web browser
- Are hosted on a different domain than trackvia.com
- Or call the TrackVia API directly from client-side JavaScript
May now experience errors such as:
Access to fetch at 'https://go.trackvia.com/...' from origin 'https://yourdomain.com' has been blocked by CORS policy.
Why HTTP Requests Fail
Browsers enforce CORS for script-initiated cross-origin requests.
When a request is not "simple", the browser first sends a preflight OPTIONS request that asks whether the request is allowed by the backend. Common preflight triggers include:
- Custom request headers
- Non-safelisted Content-Type values (for example application/json)
- Methods other than GET, HEAD, or form-style POST
If TrackVia does not return the expected CORS allow headers, the browser blocks the request.
How to Resolve the Issue
Option 1: Use New Native TrackVia Capability: Public Web Forms
If your custom web experience is form-based for data collection, you can easily switch to using TrackVia’s recently added Public Forms feature.
This will allow you to remove your current web form experience and instead leverage TrackVia’s native capability for you to build any number of custom forms within TrackVia to then expose them publicly via web link or QR code for instant, unauthenticated data collection.
If you have questions about adopting Public Forms, please contact your account manager directly or reach out to us at support@trackvia.com.
Option 2: Move TrackVia API Calls to a Backend Server
To resolve CORS errors, API calls should be moved from the browser to a backend server that you control.
Instead of your website’s JavaScript calling the TrackVia API directly, your application should send requests to your own server first. Your server then makes the request to the TrackVia API and returns the response back to the browser. Because the request to TrackVia is now server-to-server, it is not subject to browser CORS restrictions.
In practice, this means leveraging an existing backend service you manage or creating a small API proxy backend service. Your frontend sends data to this endpoint, and the backend securely includes your TrackVia API credentials when making the request to TrackVia. The backend receives the API response and passes the results back to the frontend application. This approach both resolves CORS issues and keeps API credentials out of client-side code.
Alternatively, many integrations use cases can be satisfied by implementing then via Workato or Microservice.
If you have questions about implementing a replacement solution, please contact your account manager directly or reach out to us at support@trackvia.com.
References
Comments
0 comments
Please sign in to leave a comment.