Content Gateway

Content Gateway

View as Markdown

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.

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 incremental ingestion, ReBAC permissions, and is what new integrations should use. See Legacy Gateways only if you are maintaining an existing integration.

Endpoints at a glance

EndpointPurpose
GET /v1/filesPaginated file listing (OData-style cursoring)
GET /v1/files/{id}Single file metadata, plus HTML body for KBA-style content
GET /v1/files/{id}/downloadBinary content for files (PDF, PPTX, DOCX, TXT)
GET /v1/files/{id}/permissionsPer-file ACL (used in ReBAC mode)
GET /v1/usersUser directory
GET /v1/groupsGroup directory
GET /v1/groups/{id}/membersGroup membership
GET /v1/permission_modelDeclares which permission model your gateway uses
GET /v1/permissionsPermission tuples (alternative to per-file ACLs)

Full request and response schemas are in the Content Gateway API spec.

Permission models

The gateway supports two access-control approaches. Your gateway declares which one it uses through the /v1/permission_model endpoint.

ModelUse when
PublicAll ingested content is visible to every employee who can use the AI Assistant. Simplest setup; skip the user, group, and permission endpoints.
ReBACPer-file access control based on users and groups your gateway exposes. Use when content visibility differs by audience.

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, error response shapes, and rate-limit headers - you only write the source layer (calling your API and field mapping).

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

PageWhat it covers
Starter CodeFlask reference implementation, what’s pre-built vs what you write, deployment options
Verifying Your BuildSchema conformance checker (validate.py), what each check tests, common failure modes
Connecting Your Gateway to MoveworksConnector creation, ingestion config, end-to-end verification
AuthenticationAPI Key and OAuth 2.0 Client Credentials setup
ErrorsError response format and the full set of error codes Moveworks expects
Supported MIME TypesFile formats accepted (PDF, PPTX, DOCX, TXT, HTML for KBAs)
Content Gateway API specFull endpoint reference with request and response schemas

FAQs

Can I build my own APIs that have custom endpoints and responses?

No. The Content Gateway approach relies on you following the Moveworks Gateway spec. The spec is designed against oData and API design best practices so it stays consistent across customers and source systems.

What if I have multiple backend systems?

Build one gateway per source system. Moveworks will integrate with as many gateways as you stand up. Most of the gateway scaffolding is reusable across sources - you can duplicate a working gateway and swap out the source-layer logic.

How does rate limiting work?

Moveworks will make as many API calls as the gateway accepts. Enforce rate limits on your side using the Retry-After header on a 429 response. See Errors for the full error contract.

Get help