OAuth setup

OAuth applications

OAuth applications let you connect Contracts AI to other software—internal portals, automation, or approved add-ins—using standard OAuth 2.0 flows. Instead of sharing passwords, users sign in through Contracts AI and your app receives tokens to call APIs within your organization’s rules.

Why this is useful

• Secure integrations — Third-party tools get scoped API access via OAuth rather than static credentials tied to one person’s password.
• User context — Flows can run as the signed-in user, which helps with auditing and least-privilege access.
• Operational control — Admins can register, disable, rotate, or remove integrations from one place.

Common cases

• Microsoft Word add-in / plugin — A registered app (for example, contracts-ai-word-plugin) uses redirect URIs that point at the add-in’s OAuth callback (often localhost during development and your production URL when deployed).
• Internal tools — Custom dashboards or procurement systems that read contract metadata via your APIs after OAuth.
• Partner integrations — Vetted vendors where your security team approves a fixed redirect URI list.

Exact API paths, token behavior, and scopes are documented in the API documentation. This admin screen is where you register the client your integration uses—not where you configure every HTTP detail.

---

Where to configure

Go to Admin → Security tab → Manage OAuth Applications (panel title: OAuth Applications).

The intro explains that you manage OAuth applications for API access and can create integrations for your corporate or third-party applications.

---

Create a new application

1. Click Create Application to open New OAuth Application.
2. Fill in:
   • Application name (required) — A short name you’ll recognize (placeholder example: My Integration). This is the human-readable label for the registration.
   • Redirect URIs (required) — Comma-separated list of allowed redirect URLs where the authorization server may send the user after login/consent (placeholder example: https://example.com/callback). Only URIs you list here should be used by your client.
3. Click Create (or Cancel to close).

After a successful create, the app shows a toast with the Client ID—copy it immediately and store it with your integration; you’ll need it in your client configuration alongside the redirect URI(s).

The product creates the application with the authorization code grant type (as implemented in the app).

---

Manage existing applications

Under Applications (N) each registered app shows:

• Name and an active (green check) or inactive (red X) indicator.
• Client ID — Shown in a code-style block. Use Copy Client ID to copy it.
• Redirect — The allowed redirect URI list stored for that app.

Actions on each application

Action	What it does
Activate / Deactivate	Turn the integration on or off without deleting it. Deactivated apps should not complete new authorizations.
Delete	Permanently removes the application. Existing Client IDs stop working—confirm before deleting.
Copy Client ID	Copies the Client ID to the clipboard for pasting into your app or secrets store.
Regenerate Client ID	Issues a new Client ID; the old one stops working. Update every deployment that still uses the old ID.

---

Scope and API reference

This screen does not expose a separate Scope picker—the UI focuses on application name, redirect URIs, and Client ID management. For scopes, endpoints, and integration steps, use your org’s API docs:

API documentation

---

Practices

• Register exact redirect URIs for each environment (dev/stage/prod); avoid wildcards unless your security standards allow them.
• Regenerate Client ID only during rotation or if a credential may have leaked; plan downtime or parallel cutover for dependent apps.
• Deactivate first when testing whether an integration can be safely removed, then delete when you are sure.

---

Permissions

Only appropriate admin roles can open OAuth Applications. If you do not see it, ask your administrator.