ORCID-Source Documentation

repository·main·Indexed 20 days ago

https://github.com/orcid/orcid-source

A collection of web applications and libraries powering the ORCID registry, providing infrastructure for researcher identity management via RESTful APIs, web interfaces, and data models. Includes documentation for the ng-orcid Angular app, ActiveMQ broker configuration, the orcid-activities-indexer for JMS message processing, and comprehensive manual and automated testing procedures for registration, OAuth linking, and Public API authorization.

Tokens
68.1K
Snippets
211
Records
326
Agent score
67%

What's inside ORCID-Source

  1. Overview of ORCID APIs

    main

    ORCID provides two distinct APIs for interacting with its registry:

    1. Member API: Allows reading and writing limited-access information. This is available to organizations that are ORCID members.
    2. Public API: Allows reading public-access information. This is available for anyone to use.

    Both APIs follow the same workflow for requesting access and making calls. For testing, ORCID provides a Sandbox environment (https://sandbox.orcid.org/) where you can test the Member API without being an ORCID member.

  2. Overview of Peer-Review and Group-ID workflows

    main

    This tutorial covers the management of peer-review activities and the Group-IDs required to post them.

    Key Constraints:

    • Peer-review items: Can only be added or updated by API clients. Users can delete them, but cannot add or edit them via the ORCID interface.
    • Group-IDs: Required for posting peer-review items. If you use a valid ISSN as your Group-ID, the system automatically generates it, and you can skip the manual Group-ID creation process.

    Technical Details:

    • Activity Type: peer-review (follows the CASRAI Peer Review Services data profile).
    • Required Scopes:
      • For peer-review items: /activities/update and /read-limited.
      • For peer-review groups: /group-id-record/update and /group-id-record/read.
    • Authentication Methods:
      • 3-step OAuth: Used for posting peer-review items.
      • 2-step authorization: Used for creating peer-review groups.
    • Primary Endpoints:
      • /peer-reviews and /peer-review (for items).
      • /group-id-record/update (for groups).
  3. Overview of ORCID-API-Common

    main
    The orcid-api-common package contains shared API components and logic that are utilized by both the public (t1) and member (t2) ORCID APIs. Developers working with ORCID API integrations should look to this package for common data structures, utilities, or logic shared across different access levels.
  4. Overview of ORCID-Core

    main
    ORCID-Core provides the fundamental functionality for the ORCID Registry. It manages the interactions between different components of the ORCID data model and provides the functions necessary to perform operations on that model. Additionally, it handles logic related to 'visibility' (privacy settings) within the registry.
  5. Overview of the ORCID-Pub-Web Public API

    main

    The ORCID-Pub-Web webapp provides a RESTful public API for accessing ORCID data.

    Key characteristics:

    • Format Support: The API supports both XML and JSON responses.
    • Data Privacy: Only information explicitly marked as public by the contributor can be queried via this API.
    • Architecture: It follows RESTful principles.
  6. What is Token Delegation

    main

    NOTE: The Token Delegation feature is no longer available.

    Historically, Token Delegation allowed an ORCID member to transfer permissions granted to their client to another member client. This enabled a second client to perform actions (such as posting to the user's ORCID record) on behalf of the original client.

    This feature could be used with Member API credentials on sandbox or production servers using version 3.0_rc2 or greater.

  7. Handle incoming webhook calls

    main

    When an ORCID record is updated, the ORCID Registry will send an HTTPS POST request to your registered URL.

    Webhook Call Characteristics:

    • Method: POST
    • Body: Empty
    • Frequency: Notifications are sent approximately every five minutes to aggregate changes and avoid excessive calls.

    Handling the Request:

    • Your server must respond with a 2xx status code (e.g., 204 No Content) to acknowledge successful receipt.
    • If your server returns a non-2xx code, the ORCID Registry will retry the call, doubling the time between each subsequent attempt.
    # Example of the call your server will receive
    curl -v -X POST https://nowhere2.com/0000-0002-7253-3645/updated
  8. Permissions and Scopes for Personal Information

    main

    Accessing and editing personal information in an ORCID record requires specific OAuth scopes and follows strict permission rules:

    Required Scopes

    • /person/update: Required for writing/editing information.
    • /read-limited: Required for reading person items.

    Edit Permissions

    Not all fields can be edited via the API. The API enforces a distinction between what a researcher can edit directly and what an application can write on their behalf:

    • User Edit Only (Cannot be written via API): given-name, family-name, credit-name, biography, and emails.
    • API Writable: other-names, address:country, keywords, researcher-url, and external-identifiers.

    Note: Most researchers set email addresses to private, making them unreadable via the API.