> For clean Markdown of any page, append .md to the page URL. > For a complete documentation index, see https://help.moveworks.com/llms.txt. > For full documentation content, see https://help.moveworks.com/llms-full.txt. # Content Gateway > Build a customer-hosted API that serves files, users, groups, and permissions to Moveworks for ingestion and search. # 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](/Enterprise-Search/copy-of-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](/api-reference/legacy-gateways/authentication) 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 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/users` | User directory | | `GET /v1/groups` | Group directory | | `GET /v1/groups/{id}/members` | Group membership | | `GET /v1/permission_model` | Declares which permission model your gateway uses | | `GET /v1/permissions` | Permission tuples (alternative to per-file ACLs) | Full request and response schemas are in the [Content Gateway API spec](/api-reference/content-gateway/content-gateway/list-files). *** ## Permission models The gateway supports two access-control approaches. Your gateway declares which one it uses through the `/v1/permission_model` endpoint. | Model | Use when | | ---------- | ----------------------------------------------------------------------------------------------------------------------------------------------- | | **Public** | All ingested content is visible to every employee who can use the AI Assistant. Simplest setup; skip the user, group, and permission endpoints. | | **ReBAC** | Per-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](https://github.com/moveworks/gateway). 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](/api-reference/content-gateway/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](/api-reference/content-gateway/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](/api-reference/content-gateway/moveworks-setup). ### 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](/api-reference/content-gateway/authentication). *** ## Reference pages | Page | What it covers | | -------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------- | | [Starter Code](/api-reference/content-gateway/starter-code) | Flask reference implementation, what's pre-built vs what you write, deployment options | | [Verifying Your Build](/api-reference/content-gateway/verifying-your-build) | Schema conformance checker (`validate.py`), what each check tests, common failure modes | | [Connecting Your Gateway to Moveworks](/api-reference/content-gateway/moveworks-setup) | Connector creation, ingestion config, end-to-end verification | | [Authentication](/api-reference/content-gateway/authentication) | API Key and OAuth 2.0 Client Credentials setup | | [Errors](/api-reference/content-gateway/errors) | Error response format and the full set of error codes Moveworks expects | | [Supported MIME Types](/api-reference/content-gateway/supported-mime-types) | File formats accepted (PDF, PPTX, DOCX, TXT, HTML for KBAs) | | [Content Gateway API spec](/api-reference/content-gateway/content-gateway/list-files) | Full 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](https://www.odata.org/documentation/) 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](/api-reference/content-gateway/errors) for the full error contract. *** ## Get help * [Moveworks Professional Services](https://www.moveworks.com/us/en/professional-services) - engagement to build the gateway for you * [Moveworks Community](https://community.moveworks.com/) - questions, edge cases, ongoing discussion * Your Moveworks Customer Success contact for production deployments and escalations