Skip to main content
API Preview
Build

ORCID iD

Pairing ORCID lets ~Alter recognise the research-identity surface of your life: the works you've published, the institutions you've sat inside, the persistent identifier the scholarly world already keeps for you. T1 is the iD-claim; T2 confirms ownership via ORCID OAuth.

What pairing does not authorise

Pairing this connector is a read commitment, not delegation. Specifically, ~Alter cannot use this pairing to:

  • •Write to, modify, or annotate your ORCID record in any field.
  • •Add or remove works, employments, educations, peer reviews, or funding entries.
  • •Change your ORCID privacy visibility settings or trusted-organisation list.
  • •Submit on your behalf to any journal, repository, or grants portal that consumes ORCID auth.
  • •Read any private ORCID record field, even when the OAuth token would technically permit it. The connector requests the smallest read-only scope ORCID supports.

The OAuth or attestation scope we request is the minimum required to recognise the pattern described in What we read. Anything beyond that is structurally refused at the connector boundary, not promised by trust. How pairing works.

What we read

  • Your 16-digit ORCID iD (formatted like 0000-0002-1825-0097) as you enter it.
  • Your given and family name from the public ORCID record.
  • Your public works list: titles and DOIs, fetched once at pairing to derive scholarship-breadth and cross-discipline signals.
  • OAuth-confirmed ownership flag once you sign in with ORCID. This is what upgrades T1 to T2.

What we don't read

~Alter explicitly refuses these fields even when the OAuth scope or API permits them. Every refusal is enforced at the connector boundary, not by trust.

  • Private ORCID record fields, even when the OAuth scope grants access.
  • Biography, employment history, and education history. These fields exist on the public record but the connector does not fetch them.
  • Email addresses associated with the ORCID record.
  • Funding records or peer-review history.
  • Co-author graph beyond what is already public in the works list.
  • Trusted-organisation lists ORCID maintains on your behalf.

Where it lives

The iD + tier badge sits in ~alter's pairing ledger keyed to your ~handle. Public-record snapshots are refreshed on demand, never proactively scraped, and superseded on every re-check. The OAuth access token is short-lived and discarded after the T2 upgrade confirmation.

How to revoke

Revocation is immediate. Ask the AI client you paired through to revoke this connector, or revoke it from your consent surface over the same connection. Either path revokes the provider token, stops all further reads, and purges the derived signals this connector fed into your identity vector. An audit row records the revocation.

One thing is kept on purpose. The connector retains a record that this account was paired and when it was disconnected, so the same account cannot be unpaired and re-paired in quick succession to churn your identity vector. That cooldown record holds the raw profile snapshot until the window passes. It is never read into a new signal while disconnected, and it is not shared with anyone.

Prefer the command line? The CLI is the optional deeper path and revokes the same connector:

CLI (optional)

alter unpair orcid

Pairing this connector does not enrol you in any matching, ranking, or matching surface. Every downstream use requires its own consent row. See the consent model.