Ironclad | DataGrail Documentation

Unlisted page

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 IroncladPublic 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.

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.

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

Need help?

If you have any questions, please reach out to your dedicated Account Manager or contact us at support@datagrail.io.

Disclaimer: The information contained in this message does not constitute as legal advice. We would advise seeking professional counsel before acting on or interpreting any material.