NetDocuments is a cloud document management platform used to store, organize, and search legal and professional documents. The NetDocuments integration with Frontegg connects to the NetDocuments REST API, letting your application browse cabinets, folders, and workspaces, read and rename documents, replace document content and add new versions, file documents into folders, search across cabinets, and look up users and security groups on behalf of your users.
Prerequisites
Prerequisites
- A NetDocuments repository, and a repository administrator who can authorize the application
- A NetDocuments Developer Portal account — this is not self-serve and must be requested from NetDocuments support before you can register an application
- The data region your repository is hosted in: United States, European Union, Germany, or Australia
NetDocuments does not offer self-serve access to its Developer Portal. Sign in to NetDocuments support, choose Submit a Request, select API Support as the help-desk category, and use Request Dev Portal account as the subject. NetDocuments creates the account and emails you a sign-in link.
Your Developer Portal sign-in is separate from your everyday NetDocuments sign-in, even when both use the same email address.
Sign in to the Developer Portal and register a new application. Set the client type to Confidential — the integration keeps its credentials on the server and exchanges them for tokens directly, which a public client cannot do.
Give the application a name your repository administrator will recognize, for example Frontegg Integration.
In the application's settings, enter the redirect URL shown in the Frontegg portal for this integration — copy it whole, including the path. See How to get your Redirect URL.
The value has this shape, but take the real one from the portal rather than assembling it:
https://YOUR_MCP_GATEWAY_URL/integration-callback
The redirect URL must match exactly
The redirect URL must match exactly
NetDocuments compares the redirect URL in the authorization request against the registered value character for character, including the protocol and any trailing slash. A mismatch fails the connection before the consent screen appears.
The integration requests the three scopes below. Grant all three — the connection is authorized once for the whole integration, so a missing scope disables the matching operations rather than prompting again later.
| Scope | Description |
|---|---|
read | Read cabinets, folders, documents, workspaces, users, and groups, and run searches |
organize | Create folders and file documents into or out of them |
edit | Rename documents and folders, replace document content, and add new versions |
NetDocuments generates the Client ID and Client Secret when the application is registered. Copy both and store them somewhere safe — you will need them when configuring the integration in the Frontegg portal.
Keep your credentials secure
Keep your credentials secure
Treat the Client Secret like a password. Never share it or commit it to version control. If it is exposed, generate a new one in the Developer Portal and update the Frontegg portal.
Before the application can reach a repository, a repository administrator must approve it and map your Client ID to the identity the application acts as inside that repository. Send the administrator your Client ID and the application name from step 2.
Until this mapping exists, the credentials are valid but every call is refused by the repository.
Once you have your Client ID and Client Secret from the steps above, enter them in the integration configuration page of the Frontegg portal:
- Open the Frontegg portal and navigate to [ENVIRONMENT] → Integrations → NetDocuments.
- Enter the Client ID and Client Secret in the corresponding fields.
- Select your Data region — United States, European Union, Germany, or Australia.
- Select the required scopes.
- Click Save.
The data region must match where you registered
The data region must match where you registered
NetDocuments runs separate regional services, and credentials are issued per region. A Client ID registered in the United States is not valid against the European Union, Germany, or Australia, so selecting the wrong region here fails the connection even when the credentials are correct.
- Document content can be replaced in place without creating a new version, or added as a new version that leaves the previous one intact — the choice is yours per update.
- A new version can be created by copying an existing version instead of uploading content again.
- Searches can run against a single cabinet or across several cabinets at once, with paging for large result sets.
- Invalid characters in a new folder name can be stripped automatically instead of failing the request.
- Document content can only be sent as text. Binary files — PDFs, images, Office documents — cannot be uploaded or replaced through the integration, though they can be downloaded, optionally encoded as text.
- Every result is filtered by what the connected user is allowed to see. A short or empty list of cabinets, folder items, search results, or groups is not proof that nothing else exists — it may mean the connected user cannot see it.
- Searches and container listings return at most 500 items per request, and a cabinet search returns 100 by default unless a higher limit is asked for.
- Filing a document into a folder gives it the access rights of that folder, so organizing documents can change who is able to reach them.
- Multi-cabinet search requires the cabinets to be named explicitly; there is no way to search every cabinet at once without listing them.
- Identifiers are prefixed by type and are not interchangeable — cabinet identifiers begin with
NG-and group identifiers withUG-. Supplying one where another is expected is rejected. - Renaming a document or folder changes only its name; contents, location, and version history are left as they are.