API Developer Policy
Table of Contents
Castor is making medical research faster and smarter. As part of this, we pride ourselves in exposing extensive APIs to our products’ functionality and data having some of the most advanced APIs in our industry to enable you and your engineering teams to fully harness the power of our software. To further these goals, we’ve crafted the Developer Policy as a guide to help people understand our rules and expectations about appropriate API production and consumption.
The below Policy is applicable to our public APIs for EDC & eConsent. The API documentation for these API’s can be found here:
eConsent API: https://api.us.castorconsent.com/docs
EDC API: https://data.castoredc.com/api
Permitted use
The provided API documentation should be followed when interacting with our API’s.
API integrations must not negatively impact application performance or end-user experience within the corresponding application. Where API endpoints have automatic rate limits, these limits are communicated via the X-RateLimit HTTP response header. For those API endpoints that do not (yet) have system-enforced limits, we ask that you not exceed 100 requests per minute to avoid overloading our systems.
Library authors: when building client libraries to interact with our APIs, we ask that you design these to send a recognizable user-agent header by default. We recommend using the scheme {language_ecosystem}-{package_name}/{package_version}; for example python-castoredc_api/1.2.3
We will monitor the use of our API for compliance with this procedure, and may deny access to the API without prior notice when noncompliance is detected.
API integrations must not negatively impact application performance or end-user experience within the corresponding application. If Castor finds any indications of issues with your integration, we might contact you to request changes to the integration. If these changes are not made, we might deny access to the API.
We will monitor the use of our API for compliance with this procedure, and may deny access to the API without prior notice when noncompliance is detected. In applications where API requests are automatically rate limited, these limits are communicated via the X-RateLimit HTTP response header.
When exporting data from Castor’s systems, 21 CFR Part 11 and Annex 11 require that you validate that data is not altered in value and/or meaning during the migration process. Castor ensures all its API functionality is validated according to our specifications, it’s the responsibility of the API consumer to ensure system validation is performed for any downstream processing.
Why do our APIs not have versions?
To provide a smoother developer experience to our users, Castor has chosen a versionless API design approach. To achieve this, each endpoint and entity has its own status (See section: API Statuses & support). This allows us to make non-breaking changes to our API without the need for version changes in the consumer application. All breaking changes to our API follow a deprecation procedure, outlined below.
Changes to our API that use a deprecation status
We update our API’s without deprecating resources, operations or fields when they do not break backwards compatibility or when they are in Beta status. We consider changes to be backward compatible when they:
- add new optional fields, operations or resources, or
- broaden the scope of valid input options for a field.
The documentation for these changes is available after a new release.
For other changes we do use a deprecated status, and provide a sunset date to give our customers time to update their API integration. This date is communicated through the Sunset HTTP response header, as described by RFC8594.
Versioning change management
Castor might make backwards incompatible changes with a clear alternative, or discontinue features without a replacement being available. If such a situation arises, the consumers will be adequately informed and a migration plan will be made available.
API Statuses & Support
The below table is an outline of how we would apply status to an API version, and what the implications of those statuses are.
These statuses can be defined on a resource, operation and/or field level. There is a documented status for at least the resources, and documented statuses for operations and/or fields only when they differ from their corresponding resource. This documented status can be found in the public API documentation.
Furthermore, kindly contemplate examining the API changelog for additional information regarding the recent updates.
Ownership
Castor owns all rights, titles, and interest in the Service and the APIs, including all intellectual property rights, marks, code, and features. The client is not to infringe, reverse engineer, or copy Castor’s code, design, or content. Clients may not access our APIs in order to compete with our Service. Any rights not expressly granted by this Procedure are withheld, so if you don’t see it here, then it’s not a right we’re giving you. You own all rights, titles, and interest in the Integration, except for the APIs, our marks, and the Service. If you provide feedback about the APIs or the Service, we may copy, modify, create derivative works, display, disclose, distribute, or use that feedback without any obligation to you.
Please note that Castor may monitor client use of our APIs to improve our offerings, examine any commercial use, and to ensure compliance with the client’s use case and this procedure.