All requests to the Synap API must be made over HTTPS. Any attempt to access the API over HTTP will be rejected. This ensures that data in transit is encrypted and protected from man-in-the-middle attacks.In addition to HTTPS for data in transit, all data stored by Synap is encrypted at rest. We adhere to industry-standard encryption practices to safeguard your information.
The vast majority of endpoints within the the Synap API require authorisation. Authorisation is handled through Personal Access Tokens (PATs). A missing, invalid or revoked PAT will result in a 401 Unauthorized error.The Synap API has select few endpoints that enable "public" access without authorisation. This is because at Synap, we dogfood our API, i.e. the same API is used to power the Synap web and mobile applications. Given that your own users need to visit your Portal first as "unauthorised" prior to entering credentials and authenticating themselves, the API allows such visitors to load the basic details relating to Portal, sufficient for loading the Welcome page along with your branding.These "public" endpoints are subject to stricter rate-limits and maybe subject to "captcha" challenges. There are currently no particular use-cases for using these endpoints when building integrations. This means that we do not expect you, as a third-party developer to make use of the public endpoints, although we cannot strictly-speaking restrict your access outside of rate-limits, CORS or captchas.
PATs are long-lived and do not expire automatically. Treat these tokens as sensitive credentials; they should be stored securely and never hard-coded into client-side code or version control systems. If a PAT is suspected to be compromised, it can be revoked immediately via the Synap platform.
Access to API resources is governed by a flexible permission system built into the Synap platform. Permissions are customized by your organisation on a per-group basis, and users are granted privileges based on their group memberships. Actions are constrained by the policies defined by your organisation. These privileges are upheld by the use of PATs and Subject-User headers in requests.
To protect against abuse and ensure fair usage, the Synap API enforces rate limits on incoming requests. Exceeding the rate limit will result in temporary throttling or rejection of requests.
Synap maintains logs of API requests for a predefined period. These logs are useful for auditing, troubleshooting, and identifying potential issues within your integration. Our engineers do from time-to-time review these logs as part of support requests, or proactively when problems are suspected with the API. Please note that sensitive data, such as your PAT and PIDs are automatically scrubbed prior to being dispatch to our observability systems.
Synap actively monitors API usage for suspicious activity. While we take measures to detect and mitigate potential threats, it is your organisation's responsibility to enforce best practices in API usage, token management and correctly bounding your privileged resources to appropriate users.
To protect your resources, Synap may introduce critical security patches to the API even if they are considered breaking changes. While we aim to minimize disruption, the security of your data and operations is our top priority. In any such event you will receive communications from Synap detailing the cause, concerns and remediations, facilitating your organisation with the change where needed.
The Synap API is designed for programmatic extension and use-case customisation. It is strictly prohibited that you use this API to build a competing User Interface experience using this API. Response headers from the Synap API will not include the necessary CORS Headers to enable such integrations, and likely result in an error on most modern-browsers.If your organisation has a legitimate use-case that you believe should exempt your integration from this restriction, please get in touch with your account manager so that we can have a discussion.
