If you are trying to connect to the OCLC WorldShare API, the good news is that this is usually much simpler than people fear. In most cases, the job is not building giant middleware. The job is getting a clean authenticated bridge in place so your source system can create, update, read, and sometimes delete user records in WorldShare safely.

That means a practical OCLC WorldShare integration is often really a patron sync or identity sync problem. A library may need to connect OCLC to a student system, a membership platform, a college CRM, or an open-source tool such as CiviCRM. The hard part is rarely “can I hit the endpoint”. The hard part is making the data move cleanly enough that staff do not end up fixing duplicates and broken updates by hand.

This page is written to do two things at once:

• show the basic shape of how an OCLC WorldShare API integration works
• help the right people find me when they need help building, repairing, or modernising one

What an OCLC WorldShare API integration usually needs to do

At a practical level, a simple WorldShare API integration usually needs to do a few things well:

• get an OAuth access token with the client credentials flow
• call the WorldShare SCIM Users endpoint with that bearer token
• create a user with the required OCLC persona schemas
• read that user back and store the returned identifiers
• update the record later when the source system changes
• delete or disable records safely where the workflow requires it
• keep a correlation ID so your own system remains the source of truth

The auth endpoint is the OCLC OAuth token service, and the API endpoint follows the tenant-specific WorldShare SCIM pattern under share.worldcat.org/idaas/scim/v2/.

First clarification: this is REST, not an old SOAP integration

Some people come to OCLC expecting WSDL files, XML envelopes, and awkward SOAP client setup. For the WorldShare user-management style workflows, the shape is much closer to a modern web integration:

• OAuth client credentials
• HTTP requests
• JSON payloads
• SCIM-style resources

That is helpful because it means the main challenge is not exotic protocol work. It is disciplined integration work: credentials, payload shape, field mapping, lifecycle handling, and safe operational support.

The simple connection flow

If you want the shortest practical summary of how to connect to OCLC WorldShare, it looks like this:

1. Your system decides a user needs to be created or updated.
2. Your bridge requests an OAuth access token from OCLC.
3. Your bridge sends a SCIM user payload to the WorldShare Users endpoint.
4. OCLC returns the created or updated record with OCLC-side identifiers.
5. Your system stores the correlation between its own record ID and the OCLC-side ID.
6. Later changes reuse that mapping for updates instead of guessing or creating duplicates.

That is the essence of it. Most of the real work sits inside steps 3 to 6.

A better architecture than wiring OCLC calls straight into your app

If you are building this for a real organisation, the safest pattern is usually not “sprinkle OCLC API calls around the application”. It is better to put a small bridge layer between your source system and WorldShare.

CRM / Student System / Membership Platform
                  |
                  v
        Small internal OCLC bridge
        - token handling
        - payload shaping
        - field mapping
        - correlation IDs
        - logging / retries
                  |
                  v
      OCLC WorldShare SCIM Users API

That bridge does not need to be enormous. In fact, smaller is usually better. The point is to keep OCLC-specific logic in one place so the rest of your application talks to your clean interface, not directly to vendor-specific request code spread across random controllers or scripts.

The practical tutorial

1. Get the credentials, scope, and tenant URL right first

Before anything else, make sure you have:

• client ID
• client secret
• the OCLC token URL
• the correct scopes for user read/create/update/delete work
• your institution-specific WorldShare SCIM base URL

If these are half-configured, the rest of the project becomes confusing fast. A surprising number of integration delays are not coding problems at all. They are scope or environment problems.

2. Request the bearer token with HTTP basic auth

A typical token request uses base64-encoded client_id:client_secret in the Authorization: Basic ... header, then posts form data with grant_type=client_credentials and the required scope.

$headers = [
  'Authorization: Basic ' . base64_encode($clientId . ':' . $clientSecret),
  'Content-Type: application/x-www-form-urlencoded'
];

$body = http_build_query([
  'grant_type' => 'client_credentials',
  'scope' => $scope
]);

If you can get and reuse that token reliably, you are through the first real gate.

3. Treat the SCIM Users endpoint as the core integration surface

From there, the main practical pattern is straightforward CRUD over the SCIM users endpoint:

• POST /Users/ to create
• GET /Users/{id} to read
• PUT /Users/{id} to update
• DELETE /Users/{id} to remove where your workflow permits it

That means you can design and test the integration like a normal resource-oriented service rather than treating it like magical vendor plumbing.

4. Build the user payload with the right OCLC persona schemas

This is where many OCLC WorldShare integration attempts stall. The body is not just a tiny generic user object. A real request normally includes the core SCIM user schema plus OCLC persona extensions for the workflow you are supporting.

Practically, your payload often needs to contain:

• the schemas array
• name fields
• email fields
• institution ID
• barcode or patron identifier
• branch or circulation fields
• ILL-related fields where relevant

A practical create-user request often includes a barcode, institution ID, branch ID, and the OCLC persona namespaces needed for WorldShare to accept and enrich the record.

5. Keep a correlation ID from your own source system

This is one of the most important design choices. Do not let OCLC become the only place you can recognise a user. Your CRM, student system, membership platform, or internal workflow should keep its own durable identifier and map that to the OCLC-side identity returned by WorldShare.

That correlation layer is what keeps later updates, reconciliation, and recovery from getting ugly.

6. Prove the full lifecycle in a small test harness

Before burying the integration inside a bigger production workflow, prove the entire lifecycle in a tiny script or harness:

• get a token
• create a test user
• read the user back
• update a field and verify the change
• delete or clean up the record appropriately

This sounds obvious, but it is one of the fastest ways to avoid a lot of later confusion. A tiny repeatable harness gives you a safe place to debug scope issues, schema issues, and mapping problems before business users are involved.

A worked example of the flow

Imagine a college library wants its CRM or membership system to create a patron record in OCLC when a person becomes eligible.

1. The source system decides a person is ready for library access.
2. Your bridge requests a token from the OCLC OAuth endpoint.
3. Your bridge builds the SCIM payload with the correct OCLC persona schema blocks.
4. The bridge posts that payload to the WorldShare Users endpoint.
5. OCLC returns the created record, including OCLC-side identifiers.
6. Your bridge stores the mapping between the source-system ID and the OCLC-side ID.
7. When the person later changes email, branch, or status, the bridge updates the existing OCLC record rather than creating another one.

That is the basic commercial value of the integration. Staff stop rekeying users by hand. Record drift reduces. The workflow becomes calmer and more supportable.

Where OCLC integration projects usually get stuck

• credentials and scopes are not fully configured
• the team has not decided which system owns the person record
• payloads are close to valid but not valid enough for OCLC persona schemas
• a one-off proof of concept exists, but nobody wrapped it properly for production
• create works, but update and reconciliation logic were never designed cleanly
• there is no safe test harness, so every change feels risky
• vendor-specific request logic ended up mixed directly into the main application

That is often where outside help becomes worthwhile. Not because the HTTP request itself is impossible, but because the surrounding integration architecture determines whether the result feels dependable six months later.

Who this page is for

This is usually a good fit if you are one of these:

• a library or college team trying to connect WorldShare to an internal business system
• a team with a CRM-to-OCLC or student-system-to-OCLC patron sync problem
• an organisation with an inherited OCLC integration that works badly or no longer has a clear owner
• a software team that proved the API works but needs help turning it into a safer production bridge
• a business or IT lead who needs someone to stabilise the integration without rewriting everything around it

What I can help with

• new OCLC WorldShare API integrations
• patron sync between OCLC and a CRM, student system, membership platform, or internal workflow
• repairing or modernising an inherited OCLC integration
• wrapping legacy integration code in a safer internal bridge
• test harnesses, logging, and lifecycle verification for create/read/update/delete flows
• broader software delivery where the OCLC connection is only one part of the operational workflow

Final takeaway

If your goal is simply to “connect to OCLC”, the simplest correct mental model is: authenticate cleanly, send the right SCIM payloads, keep a stable correlation ID, and hide the vendor-specific details behind a small supportable bridge.

That is how you turn an OCLC WorldShare API integration from a fragile technical experiment into something staff can actually rely on.