Ironclad

This documentation for the Ironclad integration describes the technical capabilities of this integration, including authorization, scopes/permissions, and utilized endpoints. For more information on how to integrate Ironclad, visit our connection instructions.

Version

This integration utilizes the Ironclad Public API v1.

Base URL

The base URL used for all Ironclad API endpoints contains the Subdomain:

https://subdomain.ironcladapp.com/public/api/v1

Endpoints Utilized

DataGrail uses the following endpoints to authorize and test the connection:

Method	Endpoint	Purpose	Docs
POST	https://subdomain.ironcladapp.com/oauth/token	Obtain access token using client credentials

---

Authentication & Authorization

The DataGrail Ironclad integration connects using OAuth 2.0 with the following credentials: Client ID, Client Secret, Subdomain, and Service Account Email.

Sensitive Credentials

Publicly exposing your API credentials can allow unauthorized access to Ironclad API endpoints by a third party. DataGrail stores your API credentials encrypted and protected.

Credentials

Ironclad connects via OAuth 2.0 using the Client Credentials Grant Flow. Your Client ID, Client Secret, Service Account Email, and (if applicable) Subdomain are obtained through the connection instructions.

Optional Subdomain

The Subdomain is optional — leave it blank to connect to the default ironcladapp.com host.

DataGrail automatically refreshes the access token after expiration to keep the connection active.

Service Account Email

The Service Account Email specifies the user context for API operations via the x-as-user-email custom HTTP header. This email must belong to a user in your Ironclad instance with appropriate permissions to access records and entities.

Scopes

The Ironclad integration requires specific scopes that must be granted in order to function for a given capability.

Scope	System Detection
public.records.readSchemas	✅
public.records.readRecords	✅
public.entities.readEntities	✅

---

Limits

Limits in Ironclad are calculated using the leaky bucket algorithm. All requests that are made after rate limits have been exceeded are throttled and an HTTP 429 Too Many Requests error is returned. Requests succeed again after enough requests have emptied out of the bucket.

• DataGrail supports requests throttling to stay within 70-80% of specified service rate limits.
• DataGrail processes API responses with HTTP 429 status to interrupt requests, waiting and retrying (using an exponential backoff strategy).

---

Capabilities

System Detection

For system detection requests, DataGrail takes the following actions:

1. Fetch record metadata to identify available record types and properties
2. Filter for vendor-type records using pattern matching for common vendor agreement types:
   • MSA (Master Service Agreement)
   • SOW (Statement of Work)
   • SaaS / Software License Agreement
   • Vendor Agreement
   • DPA (Data Processing Agreement)
   • Order Form
3. Query vendor records to extract counterparty names
4. Fetch vendor entities linked to the Data Subject
5. Return all available fields for discovered records and entities

You can edit which objects and fields you want to provide to the Data Subject via the DataGrail Portal Requests interface.

Vendor Type Detection

DataGrail identifies vendor records by matching record type names against predefined patterns. Record types must have names that match one of the common vendor agreement patterns (case-insensitive). Records without a populated counterparty name field will not be included in results.

Entity Detection

Entities are identified by their relationship type. Only entities with a relationship type of vendor are included in system detection results.

Endpoints Utilized

Method	Endpoint	Purpose	Docs
GET	/entities	Query entities with pagination
GET	/records	Query records with pagination
GET	/records/metadata	Retrieve record type metadata and properties