Content Gateway

The Content Gateway is a customer-hosted REST API that serves content into Moveworks Enterprise Search. You expose the gateway endpoints behind your own HTTPS server; Moveworks polls them on a schedule and handles ingestion (polling, diffing, retries), search indexing, and permission enforcement.

Build it once for any source system. Field mapping, content shape, rate limits, and access control all stay on your side, behind a stable spec.

How it works

┌────────────────────┐    poll       ┌────────────────────┐    serve  ┌──────────┐
│  Moveworks         │ ─────────────▶│  Your Content      │ ────────▶ │  Source  │
│  ingestion         │ ◀───────────  │  Gateway server    │ ◀──────── │  system  │
└────────────────────┘   files +     └────────────────────┘
                        permissions

You implement the spec. Moveworks does everything downstream: content normalization, indexing, AI grounding, and permission-aware search responses for end users.

When to use Content Gateway

Use Content Gateway when:

A built-in connector for your source system does not exist
You need a custom permission model (role-based or attribute-based)
You want to ingest content from multiple internal systems through one gateway
You want full control over field mapping, content shape, and rate limits

If a built-in connector already covers your source (Confluence, SharePoint, Google Drive, Zendesk, etc.), use that instead. See Built-in Content Connectors.

For a comparison of build approaches (source APIs vs web scraping), see Integration Strategies.

Content Gateway vs Legacy Gateways. The older Knowledge / Forms / Identity gateways are still supported but built on legacy search infrastructure. Content Gateway is the path forward; it supports per-file ReBAC permissions and is what new integrations should use. See Legacy Gateways only if you are maintaining an existing integration.

Endpoints at a glance

Endpoint	Purpose
`GET /v1/files`	Paginated file listing (OData-style cursoring)
`GET /v1/files/{id}`	Single file metadata, plus inline HTML body for KBA-style content
`GET /v1/files/{id}/download`	Binary content for files (PDF, PPTX, DOCX, TXT)
`GET /v1/files/{id}/permissions`	Per-file ACL (used in ReBAC mode)
`GET /v1/files/permissions/metadata`	Declares the permission model your gateway uses (must return `model: "resource_permission"`)
`GET /v1/users`	User directory
`GET /v1/groups`	Group directory
`GET /v1/groups/{groupId}/members`	Direct group members (Moveworks resolves nested groups itself)

Full request and response schemas are in the Content Gateway API spec. For the access-control model see How Permissions Work; for sync pattern, capacity planning, and rate limits see the Operational Guide; for mistakes to avoid see Common Pitfalls.

Permission models

The gateway returns ReBAC (relationship-based access control) permissions. Your /v1/files/permissions/metadata endpoint must declare model: "resource_permission", which is the only model Moveworks supports.

Approach	How
All content public	Return a single permission entry of `{"type": "GROUP", "id": "*", "action": "VIEW"}` on every file. This specific shape is the wildcard for “any user.”
Per-file ReBAC	Return per-file permission entries referencing users or groups your gateway also exposes via `/v1/users` and `/v1/groups`. Moveworks evaluates access by walking from file → permission entries → group memberships → user.

For the full permission model behavior (graph traversal, wildcard requirements, VIEW-only action), see How Permissions Work.

Implementation path

The fastest route from zero to a working gateway:

1. Get the starter code

Clone the Starter Code repo. Run it locally to verify the protocol layer works against the demo data. The starter code handles OData pagination, Bearer auth, and error response shapes; you only write the source layer (calling your API and field mapping). Rate-limit header emission is a separate opt-in for production use.

See Starter Code for the walkthrough.

2. Verify your build

Run the included validate.py script to confirm every endpoint on your running server returns responses that conform to the schema. It catches field-mapping bugs and protocol drift before Moveworks-side ingestion ever runs.

See Verifying Your Build.

3. Connect to Moveworks

In Moveworks Setup, create a Content Gateway connector pointing at your server, configure ingestion under Enterprise Search, and verify content appears in search results.

See Connecting Your Gateway to Moveworks.

4. Configure auth

Choose API Key or OAuth 2.0 Client Credentials. Set the matching value in the connector you created in step 3.

See Authentication.

Reference pages

Page	What it covers
Integration Strategies	Source APIs vs web scraping, comparison of approaches
Starter Code	Flask reference implementation, what’s pre-built vs what you write, deployment options
Verifying Your Build	Schema conformance checker (`validate.py`), what each check tests, common failure modes
Connecting Your Gateway to Moveworks	Connector creation, ingestion config, end-to-end verification
Authentication	API Key and OAuth 2.0 Client Credentials setup
How Permissions Work	The ReBAC access control model: graph traversal, wildcards, VIEW-only action
Common Pitfalls	The most frequent integration mistakes
Operational Guide	Sync pattern, capacity planning, rate limits, file size cap, FAQs
Errors	Error response format and the full set of error codes Moveworks expects
Supported MIME Types	File formats accepted (PDF, PPTX, DOCX, TXT, HTML for KBAs)
Content Gateway API spec	Full endpoint reference with request and response schemas

Get help

Moveworks Professional Services - engagement to build the gateway for you
Moveworks Community - questions, edge cases, ongoing discussion
Your Moveworks Customer Success contact for production deployments and escalations