Vendor systems can offer clients ready-built ORCID integrations, providing them the full benefits of their ORCID membership without having to build their own integration. This workflows outlines overall guidelines for building an ORCID integration as a vendor offering software to customers. When building your ORCID integration you will need to ensure that your integration allows your customers to meet the requirements for issuing Member API credentials , as well as following our integration best practices.
- Authenticate ORCID iDs using the OAuth process for individuals to ensure they’re correctly associated with their affiliations and contributions.
- Display the authenticated iDs publicly in your system as per our display guidelines, to signal to researchers that your system is plumbed to support their use of ORCID.
- Connect users’ data from your system to their ORCID records, enabling your customers to update their researchers records where required.
- Collect users’ data from their ORCID record to help populate data within your system or forms.
- Synchronize your system’s data with the ORCID Registry via a bidirectional information flow.
We recommend that you contact your Engagement Lead to discuss your integration plans before starting your development.
All systems that connect with ORCID need to store the ORCID iDs and access tokens collected, and you can also store information read from the ORCID record.
- Store authenticated iDs: Your system must be able to accept and store ORCID iDs together with the user’s information.
- Exchange authorization code: Your system must be able to capture a six-digit authorization code and exchange it for an access token immediately.
- Store the token response: Your system must also be able to accept and store ORCID iD and the access token. We do recommend that you store the full token response together with the user’s information, including:
- Persistent access tokens
- Refresh tokens
- Requested scopes
- Scope expiry
- Items to store when writing data: If your system writes data to ORCID records:
- Log interactions: Your system should record both calls made to the ORCID API and responses received; this is necessary so our team can help if a problem develops later. Ideally your client should also be able to read and share these logs.
- API selection: Your system should allow clients to select whether they are using public or member API credentials (if your system allows both).
- Data export: Your system must offer a way for your clients to export the stored ORCID iDs and token exchange data (access tokens, refresh tokens, scopes, scope expiry). If your system also writes data, then it must also include the relevant put codes with data exports.
ORCID API CREDENTIALS
ORCID requires that the organization requesting the data, i.e. your client, use their own ORCID API credentials. This clearly indicates who is requesting access to update ORCID records and is required by ORCID’s membership agreement. The organization must obtain the ORCID API credentials on their own. If you are assisting the organization in managing the system and their API credentials require changes such as updating the redirect URIs, the organization must submit the request for changes.
LET US KNOW ABOUT YOUR SYSTEM
Once you’re ready to release your system, contact us to get the process started. We’ll need to know:
- Your system’s name and developer’s name.
- A brief description of its functionality and how it connects to the ORCID Registry.
- Your availability for an integration review, so we can determine whether ORCID members must undergo a full integration review before receiving API credentials, as well as confirm how your system helps members meet Collect & Connect.
- Links to pages, presentations, and/or demo systems to which we can refer organizations so they can learn more about your system.
- Technical and administrative contacts whom we can invite to join the API users list as well as liaise directly, so you can provide your clients with the latest functionality.