ORCID Sandbox: A Developer’s Guide to Testing

The ORCID sandbox is a free, fully functional copy of the ORCID Registry — at sandbox.orcid.org — that lets developers register test accounts, request API credentials, and run real Public and Member API calls against dummy data before touching production. No ORCID membership is required to test the Member API in the sandbox, and nothing you do there can affect a real researcher’s ORCID record.

ORCID is a non-profit registry that assigns researchers a free, persistent 16-digit identifier (an ORCID iD) and connects it to their affiliations, works, and funding through a public API and a membership-tier Member API. Building an integration means testing the OAuth handshake and both API tiers in the sandbox before requesting production credentials.

• What is the ORCID sandbox and how does it differ from production?
• Public API vs Member API: which scope does your integration need?
• How do you register a sandbox client and complete the OAuth handshake?
• What goes wrong when moving from sandbox to production?
• Sandbox and API questions, answered

What is the ORCID sandbox and how does it differ from production?

The sandbox is a mirror of the production ORCID Registry running on isolated test infrastructure. It behaves the same way as the live registry, with a handful of deliberate exceptions built in for safety.

• Sandbox accounts only send verification and notification emails to @mailinator.com addresses, so registration mail never leaks to real inboxes.
• Sandbox data is not backed up and can be wiped without notice — never store anything you need to keep there.
• Anyone can request sandbox Member API credentials, even without an ORCID membership; production Member API access requires a paid membership tier.
• Base URLs differ from production, which is the detail most tutorials skip:

Under ORCID’s published integration guide, every client credential, redirect URI, and access token issued in the sandbox is scoped to sandbox hostnames only — a sandbox client ID will not authenticate against production, and vice versa. This is the single most common cause of “invalid client” errors when developers copy sandbox code straight into a production deployment.

Public API vs Member API: which scope does your integration need?

ORCID publishes two distinct APIs, and choosing the wrong one wastes weeks of sandbox testing. The Public API is free for non-commercial use and gives read-only access to publicly visible record data — no ORCID membership required. The Member API requires production membership (though not in the sandbox) and adds write access plus read access to “trusted” limited-access data that a researcher has authorised your organisation to see.

Research information systems, manuscript submission platforms, and repository software (for example, systems built on OJS) most often need Member API scopes because they write affiliation or works data back to a researcher’s record. Discovery tools and simple “sign in with ORCID” buttons typically only need the Public API.

How do you register a sandbox client and complete the OAuth handshake?

Every ORCID integration authenticates through OAuth 2.0, and the sandbox forces you to exercise the full handshake before production ever sees a request. The sequence is the same for Public and Member API integrations, only the scopes and base URLs change.

1. Create a sandbox account. Register at sandbox.orcid.org/register using a made-up @mailinator.com address so you can retrieve the verification email from the public Mailinator inbox.
2. Register a client application. From the account’s Developer Tools section (or via ORCID’s sandbox Member API request form), obtain a client ID and client secret plus a registered redirect URI.
3. Send the user to the authorize endpoint. Redirect to the sandbox authorize URL with response_type=code, your client_id, the requested scope, and your redirect_uri.
4. Capture the authorization code. After the researcher grants permission, ORCID redirects back to your registered URI with a short-lived authorization code.
5. Exchange the code for a token. POST the code, client ID, and client secret to the sandbox token endpoint to receive an access token bound to that researcher’s ORCID iD.
6. Call the API. Use the access token as a Bearer credential against the sandbox Public or Member API base URL to read or write record data.

Because sandbox credentials only work against sandbox hostnames, this whole sequence must be repeated — with new, separately issued production client credentials — once testing is complete. ORCID’s own guidance recommends reviewing its integration checklist, and for Member API integrations, demonstrating the working sandbox flow to the ORCID team, before requesting production access.

What goes wrong when moving from sandbox to production?

Most production failures trace back to configuration, not code. Watch for these before cutover:

• Hard-coded sandbox hostnames. Any string reference to sandbox.orcid.org, pub.sandbox.orcid.org, or api.sandbox.orcid.org left in production config will silently fail authentication.
• Redirect URI mismatch. The redirect URI used in the OAuth request must exactly match the one registered against that specific client ID — sandbox or production, they are registered separately.
• Wrong API tier requested. Applying for Member API production access without an active ORCID membership will be rejected; Public API access has no such requirement.
• Assuming sandbox reliability. ORCID explicitly states the sandbox carries no uptime or data-retention guarantee, so integration tests should not depend on long-lived sandbox test records.

Institutions building or commissioning a research administration system that writes to ORCID records — a current research information system (CRIS), grants platform, or repository — should budget sandbox testing time separately from production onboarding, since ORCID’s own review step for Member API access is a manual, asynchronous process.

Sandbox and API questions, answered

Does ORCID have an API?

Yes. ORCID offers a Public API for reading publicly visible record data and connecting systems without ORCID membership, and a Member API for member organisations to read trusted data and write affiliations, works, or funding to a record with the researcher’s permission.

Is ORCID API free?

The Public API is free for non-commercial use by individuals and organisations under ORCID’s Public API terms of service. The Member API, in production, requires a paid ORCID membership tier — though sandbox Member API testing credentials are free and open to anyone, member or not.

What is ORCID public API vs member API?

The Public API allows anyone to read public-access information on ORCID records via machine-to-machine calls. The Member API is restricted to member organisations and additionally supports reading limited-access “trusted” data and writing or updating a researcher’s record with authorisation.

The ORCID sandbox exists precisely because both API tiers, and the OAuth handshake connecting them, need to be exercised end-to-end — with real credentials and real error responses — before a single production request is made. Treat it as a mandatory rehearsal step, not an optional convenience: budget time for the manual Member API review, hard-code nothing that points at a sandbox hostname, and re-issue every credential fresh for production.