Solutions · Repository connectors

OpenText Content Server, searched from every FOI and public records request

AccessPoint's Content Server connector lets access staff browse the node tree, run Content Server's own searches and capture documents into an FOI, ATIP or public records request — through the REST API and OTDS, as the person asking, with the node id, version and a verified SHA-256 hash recorded on each record. It runs in your own Azure subscription or on a host beside Content Server.

Start Free Trial Request a Demo

If your organization keeps its records in OpenText Content Server — a provincial or territorial ministry, a municipality, a crown corporation or agency, a utility, a university, a US state or local agency, a UK public body — the record that answers an access request is often a Content Server document, and the access office is rarely the team that can find it. Someone in records management runs the search, exports what turned up and sends it over, and the request file gains copies stripped of their node id, their version and the category attributes that made them findable. Government of Canada department on GCdocs? See the GCdocs connector.

AccessPoint's connector puts Content Server in the same Add from… picker as SharePoint, Outlook and Teams. It works with Content Server 16.2 or later, including Extended ECM installations, through the Content Server REST API — version 2 for nodes and search — with OpenText Directory Services (OTDS) for sign-in. Staff browse the node tree from the containers you offer as roots, such as the Enterprise Workspace, a records centre or a departmental workspace: folders, compound documents, workspaces, projects and business workspaces open as containers, documents and e-mails can be captured, and paths read the way Content Server shows them, for example Enterprise/Finance/2026/Budget.docx. Search works three ways — structured, by name words, type, modified date and location; full text over document content; or a native query in Content Server's region shorthand or Livelink Query Language. The details flyout shows each node's subtype, type name, owner, version number, description and category attributes, and version history opens read-only; the capture is always the current version.

How the connector identifies itself to Content Server is a decision you make with your OTDS administrator. In token-exchange mode, the recommended one, the connector asks OTDS for an OAuth token for the AccessPoint user behind each call, so Content Server trims browse, search, versions and content for that person and its audit trail records them by name; ticket mode reaches the same result with OTDS tickets issued for the user. In either mode a call with no person behind it returns nothing, a user OTDS refuses sees the reason rather than an empty folder, and AccessPoint asks the connector to confirm access immediately before every capture. Where the access office owns the records, or while impersonation is being approved, a single read-only service account can serve every call, and AccessPoint's own rule on who may add records to the case becomes the only per-person gate.

The connector needs nothing but HTTPS to the Content Server front end and to OTDS: no Windows requirement, no domain membership and no OpenText client libraries. Where Content Server is reachable from Azure, it runs on App Service, Container Apps or Azure Functions in your subscription, with VNet integration or a Hybrid Connection to the network Content Server sits on. Where it is not, it runs on-premises as a Windows service or a Linux container beside Content Server, with Microsoft's Hybrid Connection Manager connecting outward to an Azure Relay in your subscription. The costs land in your own Azure subscription: a host with two vCPUs and 2 GB of memory is ample, and a Hybrid Connection is about USD $10 a month per listener at Azure list price, with 5 GB of relay traffic included. OpenText is a trademark of Open Text Corporation; AccessPoint connects through OpenText's published Content Server REST and OTDS interfaces and is not affiliated with or endorsed by OpenText.

Sound familiar?

Three moments every access office that searches Content Server will recognize.

The export from records management

The access office asks the records team to search Content Server for a request. A zip file arrives a week later: copies renamed on the way, with no node id, no version and none of the category attributes that explained what each document was.

The account that sees everything

To stop waiting on exports, the access office is given a broad read account in Content Server. Now everyone using it can open documents their own permissions would hide, and Content Server's audit trail records the account, never the person.

The copy nobody can match

On appeal, the reviewer asks whether the record released is the one Content Server held. The copy on file was opened, re-saved and renamed, there is no hash to compare, and the document has had two new versions since.

What to look for in a Content Server connector for FOI

These are the questions to put to any tool that reaches into Content Server for an access request — whichever one you choose.

Content Server decides what each person sees OTDS impersonation should let Content Server trim every listing, search and download for the person asking, rather than handing everyone a service account's view.
Node ids and versions, not file names Each captured document should keep its node id, path and version number, so its provenance survives a rename or a move in Content Server.
A hash taken as the bytes arrive The document should be hashed while it streams into the case and checked against what the connector declares, proving the copy is the one Content Server held.
The searches records staff already use Name, type and date filters and full-text search, plus Content Server's own region shorthand and Livelink Query Language — not only a keyword box.
Read-only, with least privilege The connector should never write to Content Server. A service account with see and see contents rights on the roots should be all it needs.
Runs wherever Content Server is reachable In Azure when the front end can be reached from there; beside Content Server when it cannot — connecting outward, with no inbound firewall rule and no VPN.

How the Content Server connector works

Built on Content Server's REST API and OTDS — the details an access office and its IT team will ask about.

The node tree, from the roots you choose

List the node ids to offer as roots — the Enterprise Workspace is node 2000 — and change them freely: provenance is keyed to node ids, so nothing captured is affected. Custom container and document subtypes can be added to the configuration.

Search three ways

Structured search by name words, type, modified date and location; full text over document content; or a native where clause in region shorthand or Livelink Query Language, validated before it is sent. Results come back relevance-ranked and trimmed by Content Server.

Every call as the person

In the token-exchange and ticket modes, browse, search, versions and content all run under the attributed user's credential, cached for ten minutes per user and renewed once on a refusal. Health checks run as the service account, so one refused user never greys the tile.

Category attributes come along

The details flyout shows each node's subtype, type name, owner, version number, description and category attributes, flattened to attribute-and-value pairs you can read at a glance.

Folder trees in one tracked job

Collect this folder… walks a workspace depth-first, each container before its contents, on a cursor that survives restarts. Filter documents by modified date, mirror the source structure, and re-run without duplicates.

Version history, read-only

Open a document's versions without leaving the picker. Capture always takes the current version and records its number on the case, with a default size cap of 50 GB per document.

Chain of custody

A frozen copy, attributed on both sides

When someone adds Content Server documents to a case, the AccessPoint API fetches them server-side — the browser never calls the connector — and streams the bytes into the case's storage in your Azure subscription, computing a SHA-256 hash as they arrive and comparing it with the hash the connector reports. Up to 10 records totalling 100 MB are captured at once; a larger selection runs as a background job. Nothing is stored at the connector except credentials, resolved paths and hashes, held in memory; it never follows a redirect, never keeps a cookie and never logs a secret, token or ticket. Each record's Source details show the node path and id, the version, the hash with its Verified, Mismatch or Not declared pill, and who captured it and when. Open in source opens the node in Content Server's Smart UI, or the classic interface if you prefer, for anyone with their own access. The connector logs every call with the AccessPoint request id, the purpose, the user, the case and the Content Server principal it ran as, while Content Server's own audit records the impersonated user.

Hashed on arrival Compared with what the connector declares, on every capture.
Attributed on both sides Content Server's audit names the person; AccessPoint's ledger names the case and the purpose.
Read-only by design The connector never writes to Content Server and keeps no copies of its own.

From Content Server to the request file

The path for an organization adding Content Server to AccessPoint:

  1. Pick the identity mode first, because it decides what to ask your OTDS administrator for: a confidential OAuth client permitted to use token exchange for Content Server, or a service account with the allowImpersonation flag set on the Content Server resource. Either way, add a read-only Content Server account for health checks.
  2. Register the AccessPoint Connectors app in Microsoft Entra ID, then deploy the connector — to App Service, Container Apps or Azure Functions, or as a Windows service or Linux container on-premises — with its Content Server and OTDS addresses, root node ids and mode, and its secrets as Key Vault references or service environment variables.
  3. If Content Server is reachable only on your own network, turn on the Hybrid Connections option in your AccessPoint deployment for the connector's host and port, and run Microsoft's Hybrid Connection Manager on the connector host until it shows Connected.
  4. Run the self-test with a real user's sign-in name, then in AccessPoint choose Settings → Connectors → Add → Remote, run Test connection, decide who may see the tile, and enable it.
  5. On a request, choose Add from… and the Content Server tile, browse or search, and add documents — or use Collect this folder… for a whole workspace — then open Source details on any record.

Go deeper

All repository connectors Every system AccessPoint can capture records from, and how to choose between a built-in and a hosted connector. Connector set-up in the docs Registering, testing and monitoring a connector, identity modes, and Hybrid Connections. GCdocs connector For Government of Canada departments: GCdocs in the federal ATIP workflow, from OPI tasking to Protected B. CMIS repositories When a built-in CMIS connection to Content Server is enough, and when this connector is the better fit. Provincial & territorial government Access and privacy for provincial and territorial ministries and agencies, under their own statutes. Municipal & local government FOI and public records for cities, counties, towns and UK councils.

OpenText Content Server Connector Questions

Can AccessPoint search OpenText Content Server for FOI and public records requests?
Yes. AccessPoint's OpenText Content Server connector brings Content Server into the Add from… picker of every request, so access staff browse its node tree, search it by name, type, modified date, location or full text — or with a native Content Server query — and add documents to the case. Each one is copied server-side into the case's storage in your own Azure subscription with its node id, path, version and a verified SHA-256 hash. The connector works with Content Server 16.2 or later through the REST API and OTDS, and it only reads; it never writes to Content Server.

Which versions of Content Server does the connector support, and has it been validated against ours?
Content Server 16.2 or later with REST API version 2 enabled, together with OTDS — including Extended ECM installations. The connector is built on OpenText's published Content Server REST and OTDS interfaces, and several of the behaviours it relies on were established from OpenText's public documentation; each one falls back safely if your server behaves differently. Because every installation is configured differently, Realizer validates the connector against your instance during onboarding, and its settings cover the points that vary — the search syntax, the link that opens a node (Smart UI or classic), which impersonation mode OTDS allows, and any custom container or document subtypes you use. Ask us about your version.

Does each person see only what their own Content Server permissions allow?
In the token-exchange and ticket modes, yes. Every browse, search, version listing and download runs as the AccessPoint user who made it, through a token or ticket OTDS issues for that person, so Content Server applies its own permissions and records the person in its audit trail. AccessPoint also asks the connector to confirm access immediately before each capture, and a refused document is skipped as access denied. In service-account mode, everyone who may add records to the case sees what that one account sees, and AccessPoint's case permissions are the gate.

Does Content Server have to be reachable from the internet?
No. If Content Server can be reached from Azure, the connector can run in your subscription with VNet integration to Content Server's network. If it cannot, the connector sits on a host beside Content Server and is reached through an App Service Hybrid Connection: a small Microsoft agent on that host dials out over HTTPS to an Azure Relay namespace in your subscription, and the tunnel carries AccessPoint's own encrypted session, which the relay cannot read. No inbound port is opened and no VPN is involved, and the connector itself only makes outbound HTTPS calls to Content Server and OTDS.

Does AccessPoint copy the Content Server document or link to it?
Both. The document is copied once into the case as a frozen copy with its hash — never a live link that could change under the request — and keeps a link back: Open in source opens the node in Content Server for anyone with their own access there. Because the node id and version are recorded, provenance survives renames and moves, and the same node at the same version is skipped rather than captured twice on one case. Version history is shown read-only; the capture is always the current version.

Should we use this connector or AccessPoint's CMIS connector for Content Server?
If your Content Server exposes a CMIS 1.1 browser binding and one service account (or an SSO gateway that accepts a run-as header) is the right gate, the built-in CMIS repository connector needs nothing hosted. Choose the OpenText Content Server connector when you want OTDS impersonation so Content Server itself trims what each person sees, Content Server's own search syntaxes, full node paths, or a server that is reachable only from inside your network.

Is there a per-connector fee for the Content Server connector?
No. Every AccessPoint plan includes the repository connectors module, so the Content Server connector costs nothing extra: pricing is a flat annual fee by organization size — $2,990, $7,990, $14,990 or $29,990 — with no per-user fees, billed through the Microsoft commercial marketplace, and there is a 30-day free trial. Azure is the only separate cost, in your own subscription: the connector's host if it runs there, and roughly USD $10 a month for each Hybrid Connection listener, at Azure list price.

Flat annual pricing, published in full. Every feature in every size — access requests, privacy impact assessments, breach response, complaints, video & audio redaction, the public portal, repository connectors, and AI Assist. No per-user or per-module fees.

  • Under 500 employees$2,990/yr
  • 500–1,999 employees$7,990/yr
  • 2,000–9,999 employees$14,990/yr
  • 10,000+ employees$29,990/yr

See full pricing Build the business case

Search Content Server Without Leaving the Request.

Start a 30-day free trial of AccessPoint in your own Microsoft 365 and Azure tenant — the Content Server connector is included in every plan, with no per-connector fee.

Start Free Trial Request a Demo