.png)
BigID Integration Guide
Integrate BigID with enterprise systems through authenticated REST APIs, scheduled workflows, asynchronous job monitoring, and selected callback mechanisms.
BigID integration options at a glance
BigID primarily integrates through authenticated REST APIs for managing data sources, starting and monitoring scans, querying data assets and findings, and working with data subjects and privacy requests where licensed modules are enabled. Scan and discovery operations are asynchronous, so integrations commonly store job identifiers and poll status until completion. Selected modules may provide callback or event-style notifications, but broad webhook coverage is not confirmed. Report or result exports may be available for particular deployments and should be verified. Martini can consume the APIs, process JSON responses, schedule incremental synchronization, apply mappings and business rules, and expose a normalized REST API to downstream applications.
| Integration point | Supported by BigID? | Common use cases | How Martini supports it |
|---|---|---|---|
| REST APIs | Yes | Manage or query data sources, scans, data assets, findings, data subjects, and privacy requests where the relevant BigID modules are enabled. | Martini can consume BigID REST APIs, transform JSON payloads, apply business rules, and orchestrate downstream writes. |
| Webhooks and outbound callbacks | Limited | Selected BigID modules or workflows may provide callback-style notifications, but broad event coverage is not confirmed. | Martini can receive documented callback notifications and use them to trigger workflows; otherwise it can use scheduled polling. |
| Bulk, asynchronous, and batch APIs | Limited | Scans and discovery jobs commonly run asynchronously and return identifiers that must be monitored. Pagination, exports, and bulk retrieval vary by endpoint. | Martini can persist job identifiers, poll status with bounded retries, process pages, and route completed, failed, or timed-out jobs. |
| Authentication | Limited | BigID API requests use deployment-specific credentials or tokens, role-based permissions, and HTTPS/TLS. OAuth 2.0 must be confirmed for the tenant. | Martini can store credentials as environment secrets and send the required authorization headers after tenant-specific configuration. |
| File and report exports | Not confirmed | Catalog, discovery, classification, privacy, or governance results may be exportable in particular modules, but no general-purpose file API was verified. | Martini can process confirmed JSON, XML, CSV, or other supported files when BigID exposes a documented endpoint or transfer location. |
| Scheduled synchronization | Yes | Polling is appropriate for scan status, findings, catalog assets, and privacy requests when callbacks are unavailable or incomplete. | Martini scheduler-triggered workflows can use checkpoints, overlap windows, pagination, and deduplication for incremental synchronization. |
| Database or analytics access | Not confirmed | BigID analyzes connected repositories, but a supported direct database interface for external integration consumers was not verified. | Martini should consume documented BigID APIs or exports rather than connect directly to BigID platform databases. |
How BigID exposes data and business events
BigID REST APIs
BigID exposes REST-oriented APIs for data sources, scans, data assets, findings, data subjects, and privacy requests, subject to API version, tenant configuration, and licensed modules.
Martini implementation pattern
Martini implementation pattern: A Martini workflow authenticates to the configured BigID tenant, calls the relevant endpoint, validates and transforms the JSON response, applies business rules, and writes or publishes the result to downstream systems. Martini can also expose a normalized REST API that shields consumers from BigID-specific contracts.
Implementation sequence
BigID Webhooks and callbacks
BigID may provide callback or event-style integrations for selected modules or workflows, but broad notification coverage for scans, findings, catalog changes, and privacy-request changes is not confirmed.
Martini implementation pattern
Martini implementation pattern: Where a specific BigID callback is documented, Martini receives the notification through an exposed workflow endpoint, verifies the request according to the agreed security model, retrieves the current BigID resource when necessary, and processes the event idempotently. Unsupported events should use polling.
Implementation sequence
BigID asynchronous jobs
Scans and discovery operations are inherently asynchronous and may return a job or scan identifier before processing is complete. Pagination, exports, and bulk retrieval must be verified per endpoint.
Martini implementation pattern
Martini implementation pattern: A workflow starts or discovers the BigID job, stores its identifier, and uses a scheduler or delayed orchestration path to poll status. Terminal states are routed separately, and long-running or failed jobs generate operational alerts.
Implementation sequence
Scheduled BigID synchronization
Scheduled polling is the reliable fallback when callback support is unavailable or does not cover the required BigID object or event.
Martini implementation pattern
Martini implementation pattern: A scheduled workflow retrieves changed data sources, data assets, findings, or privacy requests using documented filters, pagination, timestamps, or checkpoints. It uses overlap windows and stable object keys to recover from restarts without creating duplicates.
Implementation sequence
Common BigID integration patterns
Pattern 1: Synchronize BigID findings to ServiceNow
When to use this pattern
Use this pattern when data-risk or sensitive-data findings must become operational remediation work. A scheduled workflow retrieves changed findings, filters actionable severity or policy values, and creates or updates ServiceNow records without duplicating existing work.
Integration direction
Example Mapping
| BigID Field | Canonical Field | Target Field |
|---|---|---|
| finding.id | sourceFindingId | u_bigid_finding_id |
| finding.severity | riskSeverity | priority |
| finding.description | findingSummary | short_description |
| dataAsset.name | assetName | u_data_asset |
Martini implementation pattern
Martini retrieves paginated findings, applies severity and ownership rules, derives a stable key from the BigID object type and identifier, and looks up the existing ServiceNow record before writing. Transient API failures are retried with backoff, while validation and authorization errors are routed to an error workflow.
Martini capabilities used
- workflows
- scheduler triggers
- API consumption
- data mapping
- business rules
- error handling
Pattern 2: Monitor BigID scan completion
When to use this pattern
Use this pattern when operations teams need notification or downstream action after a discovery or classification scan finishes. The workflow distinguishes successful, failed, canceled, and overdue jobs rather than treating scan initiation as completion.
Integration direction
Example Mapping
| BigID Field | Canonical Field | Target Field |
|---|---|---|
| scan.id | scanIdentifier | u_bigid_scan_id |
| scan.status | processingStatus | state |
| scan.completedAt | completionTime | u_completed_at |
| scan.error | failureReason | description |
Martini implementation pattern
A Martini workflow starts a permitted BigID scan or receives its identifier, stores it, and polls the status endpoint with a bounded retry policy. Terminal results are mapped to an operations record or notification, while timeouts and repeated failures are escalated for investigation.
Martini capabilities used
- workflows
- API consumption
- scheduled orchestration
- conditional routing
- business rules
- monitoring and error handling
Pattern 3: Expose a normalized BigID data-catalog API
When to use this pattern
Use this pattern when internal applications need stable access to selected BigID assets or findings without implementing BigID-specific authentication, pagination, and response handling independently.
Integration direction
Example Mapping
| BigID Field | Canonical Field | Target Field |
|---|---|---|
| dataAsset.id | assetId | id |
| dataAsset.name | assetName | name |
| dataAsset.classification | classification | classifications |
| finding.risk | riskLevel | risk |
Martini implementation pattern
Martini exposes a controlled REST API, authenticates and authorizes callers, translates query parameters into BigID requests, normalizes tenant-specific responses, and applies filtering before returning a stable contract. Upstream errors are converted into controlled responses and logged without exposing sensitive payloads.
Martini capabilities used
- API exposure
- API consumption
- authentication and authorization
- data mapping
- business rules
- error handling
Pattern 4: Coordinate BigID privacy requests
When to use this pattern
Use this pattern where the required BigID privacy APIs are licensed and available and a request must be fulfilled across systems such as Salesforce, ServiceNow, and internal data services.
Integration direction
Example Mapping
| BigID Field | Canonical Field | Target Field |
|---|---|---|
| privacyRequest.id | privacyRequestId | external_request_id |
| dataSubject.id | subjectReference | customer_reference |
| privacyRequest.type | requestType | request_type |
| privacyRequest.status | overallStatus | state |
Martini implementation pattern
Martini receives or polls for privacy requests, retrieves the associated Data Subject and request details, invokes approved downstream APIs, and tracks completion per system. The workflow enforces authorization, masks sensitive values in logs, prevents duplicate actions, and reports partial failures for controlled retry.
Martini capabilities used
- workflows
- API consumption
- data mapping
- business rules
- secure secrets
- error handling
Applications commonly integrated with BigID
BigID can be integrated with data platforms, governance tools, and remediation applications. Availability and object coverage should be confirmed for the target BigID deployment and licensed modules.
| Application | Scenario | Direction | Martini Pattern |
|---|---|---|---|
| Snowflake | Discover, classify, catalog, and govern data stored in Snowflake, then route BigID findings to governance or remediation processes. | Snowflake → BigID → Martini → Governance systems | Use a scheduled Martini workflow to coordinate the confirmed Snowflake and BigID interfaces, normalize asset and finding results, and publish them to downstream governance workflows. |
| Databricks | Analyze lakehouse data assets and sensitive information and make classification or governance outcomes available to operational teams. | Databricks → BigID → Martini → Governance systems | Orchestrate source discovery and BigID result retrieval in Martini, then map classifications and risk outcomes to a canonical governance model with retry and checkpoint handling. |
| Amazon S3 | Discover sensitive data in object storage and catalog files or objects for privacy and security analysis. | Amazon S3 → BigID → Martini → Governance systems | Coordinate the confirmed S3 and BigID configuration, retrieve relevant BigID assets or findings through REST APIs, and route normalized results to approved consumers. |
| Salesforce | Identify personal or sensitive information in Salesforce data and coordinate privacy or governance actions. | Salesforce → BigID → Martini → ServiceNow | Use Martini to retrieve BigID findings or privacy-request details, apply authorization and data-minimization rules, and invoke Salesforce or ServiceNow APIs with idempotent tracking. |
| ServiceNow | Convert data-risk, privacy, or classification findings into incidents, tasks, or remediation work items. | BigID → Martini → ServiceNow | Schedule a Martini workflow to retrieve changed BigID findings, deduplicate by object identifier, map severity and ownership, and create or update ServiceNow records while recording failures. |
| Jira | Create and track remediation issues for sensitive-data findings, policy concerns, or data-source configuration problems. | BigID → Martini → Jira | Consume BigID REST results, transform findings into Jira issue fields, retain the Jira issue key, and synchronize later changes without creating duplicates. |
| Microsoft Purview | Coordinate catalog, classification, and governance information across data-intelligence platforms where both systems are part of the enterprise architecture. | BigID → Martini → Microsoft Purview | Expose a canonical Martini workflow or API that retrieves selected BigID results, applies tenant-specific rules, and exchanges only approved governance metadata with Microsoft Purview. |
How to build a BigID integration in Martini
Objective
Configure the BigID tenant endpoint and authentication details for the deployment and enabled modules.
Instructions in Martini
- Confirm the BigID API base URL, version, modules, roles, and required headers
- Store tokens or credentials in Martini environment secrets
- Use HTTPS/TLS and avoid embedding credentials in workflows
Objective
Select an event, schedule, or API request that matches the required synchronization behavior.
Instructions in Martini
- Use a documented BigID callback only for confirmed event coverage
- Use a scheduler for scan monitoring and incremental polling
- Define a checkpoint or overlap window for restartable synchronization
Objective
Call BigID REST endpoints and handle asynchronous jobs, pagination, and endpoint-specific response behavior.
Instructions in Martini
- Retrieve Data Sources, Scans, Data Assets, Findings, Data Subjects, or Privacy Requests as required
- Persist scan or job identifiers before polling
- Process paginated results within bounded execution limits
Objective
Coordinate BigID calls, downstream operations, conditional routes, and terminal job states in a maintainable Martini workflow.
Instructions in Martini
- Separate completed, failed, canceled, and timed-out scan paths
- Use reusable workflow logic for common authentication and error handling
- Keep privacy-request processing auditable and authorization-aware
Objective
Convert BigID-specific JSON structures and classifications into a canonical model or target application contract.
Instructions in Martini
- Map stable BigID identifiers and timestamps
- Normalize severity, classification, and status values
- Validate required fields and tolerate optional or module-specific fields
Objective
Control which results are delivered and how duplicate or sensitive operations are handled.
Instructions in Martini
- Filter findings by severity, policy, source, or ownership
- Derive idempotency keys from object type and BigID identifier
- Mask sensitive values and prevent unsafe retries for non-idempotent privacy actions
Common BigID data objects used in integrations
| Object | Typical Use | Common target systems | Martini handling |
|---|---|---|---|
| Data Sources | Represent registered repositories and systems that BigID scans or monitors. | Martini-managed catalogs, ServiceNow, Jira, governance platforms | Martini retrieves source metadata through REST APIs, normalizes identifiers and status fields, and stores checkpoints for incremental processing. |
| Scans | Represent discovery, classification, inventory, or related processing jobs executed against data sources. | ServiceNow, Slack, email, operations APIs | Martini starts or retrieves scans where permitted, persists the job identifier, polls status, and routes completed, failed, canceled, or timed-out outcomes. |
| Data Assets | Represent cataloged tables, files, columns, or other repository-specific assets discovered by BigID. | Data catalogs, Microsoft Purview, governance databases | Martini maps source-specific asset structures into a canonical catalog model and validates required fields before delivery. |
| Findings | Represent sensitive-data, classification, risk, discovery, or policy results associated with data assets. | ServiceNow, Jira, reporting platforms, governance systems | Martini filters and deduplicates findings, maps severity and classification values, and retains downstream identifiers for idempotent updates. |
| Data Subjects | Represent individuals involved in BigID privacy-management processes. | Salesforce, case-management systems, internal data services | Martini retrieves only authorized fields, masks sensitive values in logs, and correlates subjects with privacy-request workflows. |
| Privacy Requests | Represent access, deletion, or related requests associated with data subjects where privacy modules are enabled. | Salesforce, ServiceNow, internal data services | Martini coordinates downstream requests, tracks completion by system, handles partial failure, and updates or reports request status where supported. |
Authentication and security considerations
Tenant-specific authentication
BigID API authentication varies by deployment and enabled modules. Confirm the token endpoint, token lifetime, scopes or roles, and required headers in the tenant API reference. OAuth 2.0 should not be assumed unless specifically documented.
Protect sensitive data
- Store BigID credentials in Martini environment secrets.
- Use least-privilege BigID roles for data sources, findings, scans, and privacy operations.
- Use HTTPS/TLS and mask tokens and personal data in logs.
- Restrict exposed Martini APIs with authentication and authorization.
- Define retention controls for intermediate payloads and error records.
Operational considerations for BigID integrations
Asynchronous jobs and polling
Starting a BigID scan does not mean that processing is complete. Persist the scan or job identifier, poll with bounded retries, and handle completed, failed, canceled, and timed-out states separately.
Pagination and checkpoints
Data assets, findings, sources, and privacy requests may produce large result sets. Confirm the endpoint pagination model, process bounded pages, and persist checkpoints or overlap windows for restartable synchronization.
Idempotency and errors
Use stable keys based on BigID object type and identifier to prevent duplicate writes. Retry transient network and throttling failures with backoff, but do not blindly retry non-idempotent privacy operations.
Schema and testing
Response fields can vary by API version, module, and tenant configuration. Validate required fields, tolerate optional values, test representative findings and privacy cases, and monitor workflow logs for mapping or authorization changes.
Why use Martini instead of scripts or point-to-point integrations?
Centralized orchestration
Martini coordinates BigID API calls, scan monitoring, downstream updates, and exception paths in workflows rather than scattering logic across scripts or point-to-point jobs.
Reusable integration assets
Teams can expose a normalized API, reuse authentication and transformation logic, and apply consistent business rules across ServiceNow, Jira, Salesforce, and internal systems.
Operational control
Scheduled execution, checkpoints, validation, idempotency, bounded retries, and monitoring provide a maintainable approach for large result sets and long-running BigID operations.
Secure data handling
Martini supports environment secrets, controlled API exposure, field mapping, and error handling so sensitive BigID data can be processed with less unnecessary exposure.
Frequently asked questions
BigID can be integrated through authenticated REST APIs for data sources, scans, data assets, findings, data subjects, and privacy requests where the relevant modules are enabled. Scheduled polling is appropriate for asynchronous jobs and changes when callback coverage is unavailable. Selected modules may also provide callback-style notifications, which should be confirmed for the target tenant.
Yes. Martini can consume BigID REST APIs, orchestrate scan and privacy workflows, process asynchronous job status, transform JSON data, and synchronize results with downstream systems. Where documented callbacks are available, Martini can receive selected BigID notifications; otherwise it can use scheduled workflows.
No. A dedicated BigID connector is not required. Martini can integrate using BigID's confirmed native REST APIs, tenant-specific authentication methods, scheduled polling, and selected documented callbacks or exports.
Lonti does not charge an additional per-connector or per-vendor fee to integrate BigID. The integration is subject to the provisioned capacity of the Martini environment. Separate costs may apply from BigID, cloud infrastructure, or other third-party systems based on licensing, usage, and deployment model.
REST APIs are the primary recommended method. Use scheduled workflows for scan monitoring and incremental synchronization, and use documented callbacks only for events confirmed in the target deployment. GraphQL and SOAP should not be assumed because no verified general-purpose BigID interfaces were identified.
BigID may support callback or event-style integrations for selected modules or workflows, but broad coverage for every scan, finding, catalog change, or privacy-request state change is not confirmed. Martini can receive confirmed callbacks and can poll with checkpoints for unsupported events.
Martini can process documented pagination or export mechanisms in bounded batches, persist checkpoints, and use updated-since filters or overlap windows where available. Stable keys based on the BigID object type and identifier help prevent duplicate downstream records after retries or restarts.
Yes. Martini can expose a controlled REST API that authenticates callers, invokes BigID endpoints, normalizes responses, applies tenant-specific filtering and authorization, and returns a stable contract to internal applications.
Related Martini documentation
Workflows
Transformation
Integrate BigID with Martini
Use Martini to orchestrate BigID APIs, scheduled synchronization, scan monitoring, privacy workflows, and downstream governance processes in a secure, maintainable integration architecture.