.png)
OneTrust Integration Guide
Connect OneTrust privacy, consent, risk, and governance data with enterprise systems through REST APIs, selected event notifications, and orchestrated Martini workflows.
OneTrust integration options at a glance
OneTrust is primarily integrated through product-specific REST APIs covering privacy management, consent and preferences, third-party risk, assessments, data mapping, and governance. Selected products and events may provide webhook-style notifications or outbound callbacks, but coverage varies by tenant and module. Some areas also support asynchronous, bulk, export, or file operations. OneTrust APIs generally use tenant-configured OAuth 2.0 bearer tokens with scopes, roles, and permissions. Martini can consume these APIs, receive supported notifications through an API or webhook workflow, orchestrate asynchronous jobs, map payloads, and synchronize results with applications, files, or data platforms.
| Integration point | Supported by OneTrust? | Common use cases | How Martini supports it |
|---|---|---|---|
| REST APIs | Yes | Access privacy management, consent and preference, vendor risk, assessment, data-mapping, and governance resources. API availability varies by OneTrust module and tenant. | Martini can consume OneTrust REST APIs from workflows, transform responses, apply business rules, and expose normalized APIs to downstream systems. |
| Webhooks and outbound callbacks | Limited | Receive selected OneTrust event notifications for supported products and event types. Coverage is not universal across resources or lifecycle changes. | Martini can expose a receiving API or webhook workflow, validate notifications, apply idempotency, and invoke downstream processing. |
| Bulk, asynchronous, and batch APIs | Limited | Run product-specific exports, bulk operations, or asynchronous jobs for higher-volume processing. | Martini can start a job, persist its identifier, poll status, retrieve results, and deliver transformed output. |
| File and attachment APIs | Limited | Process selected documents, evidence, attachments, or exported files where the relevant OneTrust product API provides file operations. | Martini can handle file responses or stream files to target systems while applying content, size, and temporary-URL controls. |
| OAuth 2.0 authentication | Yes | Authenticate API clients with tenant-configured bearer tokens, client credentials or another supported OAuth flow, scopes, roles, and permissions. | Martini can store credentials and tenant endpoints securely, obtain tokens, refresh or reauthenticate, and distinguish authentication from authorization failures. |
| Scheduled synchronization | Yes | Poll resources without event delivery using timestamps, status filters, pagination, or change markers where supported by the product API. | Martini scheduler-triggered workflows can maintain cursors and timestamps, process pages, and resume from the last successful checkpoint. |
| GraphQL APIs | Not confirmed | No official general-purpose OneTrust GraphQL API was confirmed; REST should be treated as the standard mechanism. | Martini can consume GraphQL generally, but a OneTrust GraphQL integration should not be designed without product-specific confirmation. |
| SOAP APIs | Not confirmed | No current official OneTrust SOAP integration mechanism was confirmed. | Martini supports SOAP consumption generally, but OneTrust SOAP should not be assumed as an available endpoint. |
How OneTrust exposes data and business events
OneTrust REST APIs
REST is OneTrust's primary documented integration mechanism. Resources are organized by product area, and available endpoints, base URLs, permissions, and schemas can vary by tenant and regional deployment.
Martini implementation pattern
Martini uses REST-consuming workflows to authenticate, retrieve or update OneTrust resources, paginate through collections, apply transformations and business rules, and write results to enterprise targets or a normalized Martini API.
Implementation sequence
OneTrust Webhooks and Event Notifications
OneTrust supports event-driven integration for selected products and event types. Notifications are not guaranteed for every object or lifecycle change, so coverage must be confirmed for the tenant and API family.
Martini implementation pattern
Martini exposes an API or webhook workflow to receive supported notifications, validates the request, deduplicates the event, retrieves current OneTrust state when required, and invokes downstream orchestration.
Implementation sequence
OneTrust Bulk and Asynchronous Operations
Selected OneTrust product areas provide bulk, export, or asynchronous operations. The job model and result format are product-specific and should be verified before implementation.
Martini implementation pattern
Martini starts the operation, persists the OneTrust job identifier, polls status with bounded retries, retrieves the completed result, and transforms the output for downstream delivery.
Implementation sequence
OneTrust File and Attachment APIs
Some OneTrust product areas provide documents, evidence, attachments, or exported files. File behavior, content types, size limits, and temporary download URLs vary by API.
Martini implementation pattern
Martini receives or retrieves a supported file response, validates metadata and content expectations, and streams or transforms the file for the target system without placing sensitive contents in ordinary logs.
Implementation sequence
Common OneTrust integration patterns
Pattern 1: Orchestrate Data Subject Requests
When to use this pattern
Use this pattern when a customer portal, CRM, or service process must submit and track privacy requests in OneTrust. The flow should preserve the originating identity and request correlation while preventing duplicate submissions.
Integration direction
Example Mapping
| OneTrust Field | Canonical Field | Target Field |
|---|---|---|
| dataSubject.identifier | subject.externalId | Data Subject.identifier |
| request.type | privacyRequest.type | Data Subject Request.requestType |
| request.correlationId | request.correlationId | Data Subject Request.externalReference |
| request.status | privacyRequest.status | Data Subject Request.status |
Martini implementation pattern
A Martini API receives the request, validates required identity and request-type fields, checks an idempotency key, and submits the permitted OneTrust request. It stores the OneTrust request identifier, polls or processes supported status notifications, maps the outcome back to the originating system, and routes authorization, validation, and transient failures separately.
Martini capabilities used
- APIs
- workflows
- API consumption
- data mapping
- business rules
- error handling
Pattern 2: Synchronize consent and preferences
When to use this pattern
Use this pattern when OneTrust is the governed source for consent decisions or when a customer-facing application also captures preference changes. Event coverage should be confirmed; otherwise use scheduled incremental synchronization.
Integration direction
Example Mapping
| OneTrust Field | Canonical Field | Target Field |
|---|---|---|
| subjectId | customer.externalId | Contact.ExternalId |
| purpose | consent.purpose | Contact.ConsentPurpose |
| decision | consent.status | Contact.ConsentStatus |
| timestamp | consent.updatedAt | Contact.ConsentUpdatedAt |
Martini implementation pattern
A scheduled or notification-triggered workflow retrieves changed Consent Records or Preferences, maps purposes and channels to the target model, filters out-of-scope changes, and writes replay-safe updates. Martini maintains a timestamp or cursor, prevents duplicate updates, and retries throttled calls without retrying invalid payloads.
Martini capabilities used
- scheduled workflows
- webhook workflows
- data mapping
- transformations
- idempotency
- retry handling
Pattern 3: Publish vendor and assessment status
When to use this pattern
Use this pattern when procurement, risk, service-management, or reporting teams need OneTrust Vendors and Assessments in another operational system. Write-back should be limited to operations supported by the relevant OneTrust API.
Integration direction
Example Mapping
| OneTrust Field | Canonical Field | Target Field |
|---|---|---|
| vendor.id | thirdParty.externalId | Vendor.u_onetrust_id |
| vendor.name | thirdParty.name | Vendor.name |
| assessment.status | assessment.status | Assessment.state |
| assessment.updatedDate | assessment.updatedAt | Assessment.u_updated_at |
Martini implementation pattern
Martini retrieves paginated Vendors and Assessments, normalizes statuses and ownership, enriches records with permitted source data, and upserts them into ServiceNow using stable identifiers. It records page checkpoints, isolates rejected records, and raises alerts for permission or schema changes.
Martini capabilities used
- REST API consumption
- pagination
- data mapping
- business rules
- upsert orchestration
- monitoring
Pattern 4: Load governance data into a warehouse
When to use this pattern
Use this pattern for recurring reporting on Processing Activities, data categories, purposes, retention, consent, or assessment information. Product-specific exports or asynchronous jobs can be used when available for larger volumes.
Integration direction
Example Mapping
| OneTrust Field | Canonical Field | Target Field |
|---|---|---|
| processingActivity.id | processing.activityId | processing_activity.onetrust_id |
| purpose | processing.purpose | processing_activity.purpose |
| dataCategories | processing.dataCategories | processing_activity.data_categories |
| retentionPeriod | processing.retentionPeriod | processing_activity.retention_period |
Martini implementation pattern
A scheduler-triggered Martini workflow retrieves pages or starts a OneTrust export, persists the cursor or job identifier, transforms nested governance data into warehouse structures, and loads it with source keys and extraction timestamps. Failed pages or jobs can be replayed without duplicating successful loads.
Martini capabilities used
- scheduler triggers
- asynchronous orchestration
- pagination
- data transformation
- SQL or warehouse integration
- checkpointing
Applications commonly integrated with OneTrust
OneTrust data is commonly coordinated with customer, service-management, work-management, workforce, enterprise, and analytics platforms. Exact operations depend on the OneTrust product area, tenant configuration, and permissions.
| Application | Scenario | Direction | Martini Pattern |
|---|---|---|---|
| Salesforce | Synchronize Data Subjects, privacy requests, consent preferences, and customer identity context between Salesforce and OneTrust. | Salesforce → Martini → OneTrust | Martini receives customer or request information from Salesforce, validates and maps it to OneTrust REST resources, stores correlation identifiers, and returns request status or consent outcomes to Salesforce with retry and idempotency controls. |
| ServiceNow | Coordinate privacy requests, operational tasks, incidents, and risk workflows between OneTrust and service-management processes. | ServiceNow → Martini → OneTrust | A Martini workflow exchanges request and task data with ServiceNow and OneTrust, applies routing rules, tracks external identifiers, and handles authorization, transient failures, and duplicate updates. |
| Jira | Create or update implementation and remediation tasks associated with privacy requests, assessments, or compliance findings. | OneTrust → Martini → Jira | Martini retrieves qualifying OneTrust requests or assessment findings, transforms them into Jira issue fields, creates or updates issues, and synchronizes status using stable correlation keys. |
| Workday | Provide workforce identity or employment information for employee privacy, data inventory, and request workflows. | Workday → Martini → OneTrust | Martini retrieves relevant Workday identity data, normalizes identifiers and employment attributes, submits permitted OneTrust updates, and records processing results without exposing sensitive payloads in logs. |
| SAP | Exchange supplier, employee, customer, or business-process information used in privacy and governance workflows. | SAP → Martini → OneTrust | Martini consumes SAP APIs or approved exports, maps business and supplier context to OneTrust resources, applies validation rules, and routes rejected or unauthorized updates for review. |
| Microsoft 365 | Support privacy discovery, user identity, content governance, and data-inventory processes involving Microsoft cloud data. | Microsoft 365 → Martini → OneTrust | Martini orchestrates Microsoft 365 and OneTrust API calls, normalizes identity and governance metadata, and publishes results to the required OneTrust product area or downstream repository. |
| Snowflake | Load normalized OneTrust consent, assessment, governance, and data-mapping information into an analytics environment. | OneTrust → Martini → Snowflake | Scheduled Martini workflows paginate through OneTrust resources or retrieve completed exports, transform them into warehouse-ready structures, and load them with checkpoints and replay-safe keys. |
| AWS | Coordinate cloud data discovery, data inventory, governance, and privacy reporting across AWS-hosted data assets. | AWS → Martini → OneTrust | Martini combines AWS and OneTrust API responses, applies canonical data-asset mappings, filters changes by scope or timestamp, and publishes governance results with operational monitoring. |
How to build a OneTrust integration in Martini
Objective
Configure the tenant-specific OneTrust API endpoint and OAuth 2.0 credentials without embedding secrets in workflow logic.
Instructions in Martini
- Identify the required OneTrust product API, region, and tenant endpoint
- Configure client credentials, scopes, roles, and permissions
- Store secrets and endpoint values in Martini environment configuration
- Define separate read and write access where appropriate
Objective
Select an event-driven, API-led, or scheduled trigger based on confirmed OneTrust capabilities for the required resource.
Instructions in Martini
- Confirm whether the required OneTrust event is available
- Use a Martini API or webhook workflow for supported notifications
- Use a scheduler for polling, incremental synchronization, or job status checks
- Define correlation keys and synchronization checkpoints
Objective
Call the relevant OneTrust REST resource or receive a supported notification and obtain the current resource state when necessary.
Instructions in Martini
- Authenticate with a valid bearer token
- Process pagination and tenant-specific response formats
- Retrieve current state after an event when the notification is incomplete
- Persist job identifiers, cursors, timestamps, and source identifiers
Objective
Coordinate OneTrust calls, downstream applications, asynchronous operations, and business decisions in a maintainable Martini workflow.
Instructions in Martini
- Separate validation, retrieval, transformation, delivery, and error branches
- Apply bounded concurrency and polling intervals
- Route authorization, validation, throttling, and transient failures distinctly
- Use reusable workflow logic for common OneTrust operations
Objective
Convert OneTrust product-specific payloads into a canonical model and the target application's structure.
Instructions in Martini
- Map actual OneTrust objects such as Data Subject Requests, Vendors, and Assessments
- Normalize statuses, timestamps, identifiers, purposes, and channels
- Handle optional and product-specific fields explicitly
- Apply data minimization to sensitive personal information
Objective
Enforce privacy, authorization, scope, idempotency, and routing rules before writing or updating data.
Instructions in Martini
- Validate required identifiers and permitted request types
- Check correlation and idempotency keys before creating requests
- Filter records by tenant, product, status, or change marker
- Stop retries for authorization and permanent validation failures
Common OneTrust data objects used in integrations
| Object | Typical Use | Common target systems | Martini handling |
|---|---|---|---|
| Data Subjects | Represent individuals whose privacy requests, consent, or personal data are managed. | Salesforce, Workday, ServiceNow, customer portals | Martini validates identity and correlation fields, maps the object to downstream models, and protects personal data in workflow state and logs. |
| Data Subject Requests | Manage access, deletion, rectification, opt-out, and other privacy requests. | Salesforce, ServiceNow, Jira, customer portals | Martini submits or retrieves requests, stores OneTrust identifiers, routes by request type, and uses polling or selected notifications for status. |
| Consent Records and Preferences | Store consent, preference, purpose, channel, timestamp, and source decisions. | Salesforce, marketing applications, data warehouses | Martini maps purposes and channels, applies effective-date and idempotency rules, and supports scheduled or selected event-driven synchronization. |
| Vendors | Manage third-party vendors in privacy, risk, and governance processes. | SAP, procurement applications, ServiceNow, reporting platforms | Martini retrieves or updates permitted vendor fields, normalizes ownership and status values, and routes validation failures. |
| Assessments | Capture privacy, risk, compliance, or vendor assessment responses and statuses. | Jira, ServiceNow, Snowflake, reporting platforms | Martini synchronizes assessment summaries and statuses, maps responses to target structures, and tracks incremental changes. |
| Processing Activities | Describe processing purposes, systems, data categories, and retention information. | Snowflake, governance APIs, reporting platforms | Martini paginates and normalizes processing data, preserves source identifiers, and loads governed datasets with checkpoints. |
Authentication and security considerations
OAuth 2.0 and tenant configuration
OneTrust APIs generally use OAuth 2.0 bearer tokens, with the exact grant, audience, scopes, roles, and permissions determined by the product and tenant. Store tenant-specific regional endpoints and credentials in Martini environment configuration.
Least privilege
Separate read-only synchronization access from clients that submit or update privacy requests. Grant only the permissions required by each workflow and treat 401 and 403 responses differently.
Privacy-sensitive data
- Store client secrets and tokens in secure secrets management.
- Avoid logging complete Data Subject Request and consent payloads.
- Restrict workflow access and define retention rules for intermediate data.
Operational considerations for OneTrust integrations
Rate limits and pagination
Account for tenant- and endpoint-specific throttling. Process collection endpoints page by page, preserve required ordering, and use bounded concurrency with backoff.
State and idempotency
Persist cursors, timestamps, job identifiers, and processed event identifiers. Stable correlation keys help prevent duplicate requests and downstream updates.
Asynchronous operations
Bulk and export jobs require controlled polling and explicit handling for failure, expiration, partial results, and temporary download URLs.
Schema and testing
OneTrust resources vary by product, version, region, and tenant. Use explicit mappings, tolerate appropriate additive fields, and test changes against a representative tenant before deployment.
Why use Martini instead of scripts or point-to-point integrations?
Orchestration instead of isolated scripts
Martini centralizes API calls, triggers, transformations, business rules, checkpoints, and error branches in maintainable workflows rather than scattering logic across scripts.
Reusable integration assets
Teams can expose controlled APIs, reuse authentication and mapping logic, and coordinate OneTrust with applications, files, asynchronous jobs, and data platforms.
Operational control
Martini provides structured handling for pagination, retries, idempotency, monitoring, and environment-specific configuration, which reduces the operational burden of point-to-point integrations.
Frequently asked questions
OneTrust is primarily integrated through product-specific REST APIs for privacy management, consent and preferences, vendor risk, assessments, data mapping, and governance. Selected products and events may support webhook-style notifications, while bulk, asynchronous, export, and file capabilities are product-specific. OAuth 2.0 bearer-token authentication is generally used.
Yes. Martini can integrate with OneTrust by consuming its REST APIs, using tenant-configured OAuth 2.0 authentication, receiving supported event notifications through a Martini API or webhook workflow, and orchestrating synchronization with enterprise applications.
No. A dedicated OneTrust connector is not required. Martini can use OneTrust's confirmed native REST APIs, supported notifications, asynchronous operations, files, and authentication mechanisms through workflows and APIs.
Lonti does not charge an additional per-connector or per-vendor fee to integrate OneTrust. The integration is subject to the provisioned capacity of the Martini environment. Separate costs may apply from OneTrust, infrastructure, or other third-party systems based on subscription, usage, and deployment model.
Use the relevant OneTrust REST API as the default mechanism. Use webhook-style notifications when the required product and event support them, and use scheduled polling, exports, or asynchronous operations when event delivery is unavailable or high-volume processing requires them. GraphQL and SOAP should not be assumed.
OneTrust supports event-driven notifications for selected products and event types, but coverage is not universal across Data Subjects, Data Subject Requests, Consent Records, Vendors, Assessments, or other resources. Confirm the specific tenant capability and use polling with timestamps, status filters, or change markers when needed.
Martini can retrieve paginated OneTrust resources or process supported notifications, map product-specific payloads to a canonical model, apply business rules, and write to target applications or data platforms. Persistent cursors, timestamps, job identifiers, and correlation keys support incremental and replay-safe synchronization.
Martini workflows can distinguish expired or invalid tokens, insufficient permissions, validation errors, throttling, and transient failures. Bounded exponential backoff is appropriate for transient responses, while idempotency keys and persisted identifiers help prevent duplicate requests, events, and downstream updates.
Related Martini documentation
Workflows
Data
Connect OneTrust with your enterprise systems
Use Martini to orchestrate OneTrust APIs, supported notifications, data transformations, and reliable synchronization workflows across your application landscape.