Member API credentials check list

Member organizations receive ORCID Member API credentials on the production (live) server by completing the Production Member API client application form. Before issuing production Member API credentials, ORCID must review a demo of your integration in the ORCID sandbox. This gives us a chance to see the great integrations our members have built and offer workflow improvements, as well as checking that all integrations meet OAuth and ORCID best practices. We'll also note which elements of Collect & Connect your application meets and award badges accordingly!  

To provide a demo of your system you'll need to set up a working integration with the ORCID Sandbox that the ORCID team can preview. There are a few ways to share your working sandbox integration:

  1. Test site: If your development site is public, send us the URL along with test credentials (if needed) to access your system and instructions describing how to use your system's ORCID features. Provide additional documentation to verify what we would not be able to see from the user end, e.g. HTTPS calls, token exchange uri. 
  2. Screencast or screenshots: Send a recording or a set of screenshots with descriptions explaining and demonstrating how your integration works. Be sure to provide additional documentation to verify what we would not be able to see from the user end. 
  3. Live demo: Contact us to schedule a live demonstration. We'll provide meeting software that allows you to share your screen.

If your product is on our list of ORCID-enabled systems that does not require a demonstration, you can directly request production Member API credentials. Be sure to specify which system you're using in the notes.

Requirements for ORCID integrations

Collect & Connect 

All applications are reviewed for which elements of Collect & Connect they meet: Authenticate, Collect, Display, Connect, Sync. Your integration will receive a badge for each element it fulfils which can be displayed within your system. 

Note: Vendor systems may require additional steps to meet certain Collect & Connect elements, such as displaying the ORCID member logo or describing how your system benefits your users.


Use the latest ORCID message schema, or a supported release candidate version. Currently integrations must be using version 2.0 or higher.

Data management

  • Use OAuth to collect verified ORCID iDs and follow the OAuth 2.0 specifications. (Do not allow users search for or type in ORCID iDs.)
  • Use HTTPS for your site's redirect URIs and on ORCID API calls. No HTTP Redirect URIs will be accepted after February 2017. 
  • Use the root token uri for token exchange: https://[sandbox.]
  • Accept and store all data returned in the token exchange together with the user's data in your system
    • ORCID iD: Your system will need to know the user's iD to read or update their record.
    • Long-lived access tokens and refresh tokens to:
      • Indicate that the ORCID iD has been verified,
      • Use to read or update the ORCID iD at a later point (long-lived tokens will be valid for 20 years or until user revokes them),
      • Reissue access tokens if lost, or issue secondary access tokens for a limited scope or duration.
    • Permission scope: So you will know the permissions you have requested and received from the user.
    • Scope expiry: To know the duration of the scope -- some users may only grant short-lived permissions.
  • Accept and store put codes (if updating ORCID records): Every item that you add to the ORCID Registry will be returned with a put code by the ORCID API. Save this put code along with the item in your system—it’s how you’ll identify which item needs to be read or updated.
  • Use appropriate scopes and request methods (i.e. use POST calls to add new information and PUT calls to update existing information)
  • Log interactions: Your system should record both calls or requests made to the ORCID API and responses received. This is necessary so ORCID can help if a problem develops later.
  • Provide error messages and a support contact to your users when an interaction does not go as expected.

Best practices

  • Customize the user experience: Use data your system has stored to pre-fill the OAuth sign in/registration screen. You can also include state parameters to identify the user in your system.
  • Sign users out of ORCID before they connect their iDs: To help ensure that no iDs are incorrectly linked.
  • Provide an option for users to remove their ORCID iD and data from your system: In rare cases, a user may wish to remove their iD from your system, or they may have connected the wrong ORCID iD.
  • Use the access token to check for existing permissions: Once you have received permissions from the user once, you should not need to request them again.
  • Update added items when corrections are needed using the item’s unique put code.
  • Follow ORCID branding guidelines