Talking to OCLC WorldShare is less mysterious than many people expect. It is not necessarily a giant middleware project, and it does not need to start as a sprawling enterprise integration. In many cases, what you really need is a disciplined service that can authenticate properly, send the right SCIM payloads, and keep your business system and OCLC in sync without manual rekeying.

One real-world version of this problem was integrating a college library workflow with an open-source CRM, most likely CiviCRM or something close to it. That is a good example of why this work matters. The problem is usually not “can I hit an API endpoint”. The problem is “can I keep patron or identity data moving cleanly between two systems that were not designed together, without creating duplicate records, broken updates, or manual admin overhead”.

If you need help with that kind of work, this is exactly the sort of integration I can help design, stabilise, modernise, or build around your existing CRM, library workflow, or internal system.

What a practical OCLC WorldShare integration is actually doing

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

• get an OAuth access token with the client credentials flow
• call the WorldShare SCIM Users endpoint with a bearer token
• create a user with the required OCLC persona schemas
• read that user back, update it, and delete it again
• treat the integration like a testable service instead of a pile of ad hoc requests

The auth endpoint is the OCLC OAuth token service, and the API endpoint follows the WorldShare tenant pattern: your institution-specific share.worldcat.org/idaas/scim/v2/ base URL.

First important clarification: this is REST, not SOAP

If you are searching for OCLC integrations, you may be expecting WSDL files, XML envelopes, and classic SOAP client tooling. For WorldShare API work, the pattern is HTTP, JSON, OAuth, and SCIM-style resources. That is good news. It means the shape is much closer to modern web integration work than to old-school SOAP plumbing.

So the mental model should be: authenticate, get token, send JSON payloads to resource endpoints, handle responses cleanly.

The practical tutorial

1. Get the credentials and scopes sorted first

A common pattern here is OAuth client credentials. That means you need:

• client ID
• client secret
• the OCLC token URL
• the right scopes for what you are trying to do
• your institution-specific WorldShare API base URL

For this pattern, the scopes were things like read, create, update, and delete user access through the SCIM API. Get that right first. If scopes are wrong, everything downstream gets confusing fast.

2. Request the bearer token with HTTP basic auth

The token request is built by base64-encoding client_id:client_secret into the Authorization: Basic ... header, then posting form data with:

• grant_type=client_credentials
• scope=...

That gives you the access token used for every later API call.

$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 reliably get and reuse that token, you are through the first real gate.

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

From there, you talk to the Users resource under the WorldShare SCIM base URL. That gives you a clean CRUD model:

• POST /Users/ to create
• GET /Users/{id} to read
• PUT /Users/{id} to update
• DELETE /Users/{id} to remove

That is a much saner shape than many people expect from library software integrations.

4. Build the payload with the right OCLC schema blocks

This is the bit that catches people. The request body is not just a tiny generic user record. A real implementation usually includes the core SCIM user schema plus OCLC-specific persona extensions for things like institution, circulation info, and ILL info.

Practically, that means your payload usually needs to include:

• the schemas array
• name fields
• email fields
• institution ID
• barcode / borrower category / home branch for circulation
• ILL flags where relevant

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

5. Use a correlation identifier from your source system

One of the smartest parts of a good integration is that it does not pretend OCLC is your source of truth for everything. The returned data can include correlation information tying the record back to the originating system.

That is how these integrations should be built. Your CRM, membership system, student system, or internal workflow should keep its own durable identifier, and your bridge should map that to the OCLC-side identity. Otherwise later updates become fragile.

6. Prove the full lifecycle with a test harness

A good integration should include a small test script or harness that:

• gets an access token
• creates a test user
• reads the user back and asserts key fields
• updates the record and verifies the change
• deletes the user and confirms it is gone

This is the right way to approach OCLC work. Do not start by burying API calls inside a giant production workflow. Start by proving the integration lifecycle in a tiny testable script. Once that works, wrap it into the system that actually needs it.

A better architecture than “sprinkle OCLC calls everywhere”

If I were building this again now for a production business system, I would still keep the same basic pattern, but I would make one architectural choice more explicit: put OCLC behind a small internal service boundary.

That internal bridge or proxy should be responsible for:

• token handling
• request shaping
• schema version management
• error logging
• retry logic where safe
• mapping business-system fields to OCLC fields

Then your application talks to your clean interface, not directly to OCLC from random controller actions or UI code. That makes later changes much less painful.

Where projects usually get stuck

• credentials and scopes are half-configured
• the team is not sure which system owns the person record
• payload structure is close, but not valid for OCLC’s persona schemas
• someone built a one-off proof of concept, but nobody wrapped it cleanly for production
• the integration works for create, but update and reconciliation logic were never thought through
• there is no safe test harness, so every change feels risky

That is usually where I come in: not just writing the request code, but helping shape the integration so it is supportable by a real organisation after go-live.

What I can help with

If your organisation needs to talk to OCLC or WorldShare, I can help with:

• new OCLC / WorldShare API integrations
• patron sync between a CRM, student system, or internal platform and WorldShare
• repairing or modernising an inherited OCLC integration
• wrapping legacy integration logic in a safer internal API or gateway
• test harnesses, logging, and lifecycle verification for create/read/update/delete flows
• broader software delivery around library workflows, identity, and operational systems

This is a good fit when the hard part is not just “how do I call an endpoint”, but “how do I make this integration dependable enough that staff can trust it”.

Final takeaway

A lot of valuable integration work is not glamorous. It is careful credential handling, clear payloads, repeatable CRUD tests, and enough structure that the business stops depending on luck.

That is also why this kind of work is commercially useful. If you can make a library platform, CRM, or internal system talk cleanly to OCLC, you remove manual admin, reduce record drift, and make the surrounding workflow calmer. That is worth more than the API wrapper itself.