Ellipse Gradient for Header

Proofpoint Integration Guide

Integrate Proofpoint threat, message, click, user, and campaign data with enterprise systems through documented REST and SIEM-oriented APIs.

Proofpoint integration options at a glance

Proofpoint provides REST APIs for threat, message, click, people, and SIEM-oriented event resources, generally returning JSON over HTTPS. The documented SIEM pattern is primarily scheduled polling rather than a universal push event bus. Bounded batch or page retrieval is available for selected event data, while attachment-related metadata may be exposed by supported message or threat APIs. TAP APIs commonly use an API principal and secret with HTTP Basic Authentication. Martini can consume these APIs in scheduled workflows, persist checkpoints, deduplicate overlapping results, transform Proofpoint data, apply security rules, and deliver normalized events to SIEM, SOAR, case-management, reporting, or database platforms.

Integration pointSupported by Proofpoint?Common use casesHow Martini supports it
REST APIsYesRetrieve Proofpoint threats, messages, clicks, people, and SIEM-oriented event data over HTTPS, typically as JSON. Exact resources depend on the licensed product and tenant entitlement.Martini can consume the documented Proofpoint REST APIs from workflows, transform responses, apply business rules, and deliver results to downstream systems.
SIEM/event retrievalYesPoll selected message, click, and threat event categories for centralized security monitoring, analytics, and operational workflows.Martini scheduled workflows can maintain timestamps or cursors, retrieve event pages, normalize records, and persist checkpoints after successful delivery.
Bulk / async / batch APIsLimitedSelected SIEM and event-retrieval APIs support bounded pages or batches subject to endpoint-specific time windows, result sizes, pagination, and rate limits.Martini can control page size and concurrency, process batches, retry transient failures, and checkpoint only completed downstream deliveries.
File / attachment APIsLimitedSupported message or threat resources may expose attachment-related metadata and threat information. A general-purpose attachment download API was not confirmed.Martini can map available attachment metadata and conditionally invoke a verified product-specific endpoint, without assuming unrestricted file retrieval.
AuthenticationYesTAP APIs commonly use an API principal and secret with HTTP Basic Authentication over HTTPS; authentication varies across Proofpoint products and API families.Martini can keep credentials in environment-managed secrets and use authenticated API calls with product-specific permissions.
Webhooks / outbound callbacksNot confirmedA product-wide Proofpoint webhook mechanism was not confirmed. The documented SIEM integration approach is generally API polling.Martini can receive webhooks when a specific Proofpoint product documents a compatible callback, but implementations should default to scheduled polling.
GraphQL APIsNot confirmedNo official Proofpoint GraphQL API was confirmed in the reviewed documentation.Martini can consume GraphQL APIs generally, but a Proofpoint integration should use the documented REST APIs unless a product-specific GraphQL contract is supplied.
SOAP APIsNot confirmedNo official Proofpoint SOAP API was confirmed in the reviewed documentation.Martini supports SOAP consumption generally, but SOAP should not be assumed for Proofpoint integrations.

How Proofpoint exposes data and business events

Proofpoint REST APIs

Proofpoint documents REST APIs for threat, message, click, people, and SIEM-oriented resources. APIs generally return JSON over HTTPS, while available resources and fields depend on product, license, account configuration, and tenant entitlement.

Martini implementation pattern

Martini implementation pattern: a workflow authenticates to the applicable Proofpoint API, retrieves the required resource, validates the response, maps vendor fields into a canonical model, applies filtering and business rules, and sends the result to one or more target systems.

Implementation sequence

Authenticate with the product-specific Proofpoint API credentials
Call the required REST resource with bounded parameters
Validate and parse the JSON response
Map Proofpoint fields to the canonical integration model
Apply severity, identity, and disposition rules
Deliver the transformed result to the target system

Proofpoint SIEM event retrieval

Proofpoint SIEM-oriented APIs provide a polling-based way to retrieve selected message, click, and threat events. Retrieval may use pages, bounded batches, time windows, or endpoint-specific cursors.

Martini implementation pattern

Martini implementation pattern: a scheduled workflow reads the last successful checkpoint, requests the next event window, processes each page idempotently, and advances the checkpoint only after downstream delivery succeeds. Overlap windows account for late-arriving events.

Implementation sequence

Start the scheduled polling workflow
Read the endpoint-specific checkpoint
Request the next bounded event window
Process all returned pages or batches
Deduplicate events using stable identifiers
Write events to the destination system and confirm success before updating the checkpoint

Proofpoint attachment metadata

Selected message or threat APIs may expose attachment-related metadata and threat information. A general-purpose file-storage or unrestricted attachment-download capability was not confirmed.

Martini implementation pattern

Martini implementation pattern: the workflow treats attachment information as optional, preserves available metadata, and invokes a download operation only when the customer’s Proofpoint product documentation confirms the endpoint and permissions.

Implementation sequence

Retrieve the related message or threat resource
Check whether attachment metadata is present
Validate the supported product-specific retrieval capability
Map attachment indicators and metadata
Route unsupported or incomplete retrievals for review
Store only approved content and processing status

Common Proofpoint integration patterns

Pattern 1: Sync Proofpoint threat events to a SIEM

When to use this pattern

Use this pattern when security operations need Proofpoint message, click, and threat activity in a central monitoring platform. Polling is appropriate because Proofpoint’s documented SIEM approach is generally retrieval-based rather than a universal push event bus.

Integration direction
Proofpoint
Martini
Splunk
Example Mapping
Proofpoint FieldCanonical FieldTarget Field
threatIdevent.idevent_id
threatTypeevent.categoryevent_type
severityevent.severityseverity
eventTimeevent.occurredAttimestamp
Martini implementation pattern

A scheduled Martini workflow reads an endpoint-specific cursor or timestamp, retrieves bounded event pages, normalizes message, click, and threat categories, applies severity and allowlist rules, and submits events to the SIEM. It uses overlap windows, idempotency keys, retries, and checkpoint persistence after successful delivery.

Martini capabilities used
  • scheduled workflows
  • API consumption
  • data mapping
  • business rules
  • checkpoint persistence
  • error handling

Pattern 2: Create ServiceNow incidents from Proofpoint threats

When to use this pattern

Use this pattern when high-severity Proofpoint threats must become owned, trackable security incidents. The workflow can suppress duplicates and route different threat types or campaigns to different operational groups.

Integration direction
Proofpoint
Martini
ServiceNow
Example Mapping
Proofpoint FieldCanonical FieldTarget Field
threatIdsecurityIncident.externalIdcorrelation_id
severitysecurityIncident.prioritypriority
usersecurityIncident.affectedUsercaller_id
messageIdsecurityIncident.sourceMessageIddescription
Martini implementation pattern

Martini polls new threats, evaluates severity and campaign rules, looks up existing incidents using a stable Proofpoint identifier, and creates or updates ServiceNow records. Failed writes are retried without advancing the Proofpoint checkpoint, while unresolved identity matches are routed for review.

Martini capabilities used
  • scheduled workflows
  • API orchestration
  • data mapping
  • conditional routing
  • idempotency
  • retry handling

Pattern 3: Route Proofpoint events to a response platform

When to use this pattern

Use this pattern when analysts or automated response processes need a normalized Proofpoint payload enriched with enterprise context. It supports conditional handling for allowlisted domains, known users, or selected threat categories.

Integration direction
Proofpoint
Martini
CrowdStrike Falcon
Example Mapping
Proofpoint FieldCanonical FieldTarget Field
threatIdindicator.iddetection.external_id
urlindicator.valueindicator
campaigninvestigation.campaigncase_reference
userinvestigation.userhost_or_user_context
Martini implementation pattern

A Martini workflow retrieves Proofpoint threat and message data, applies allowlist and severity rules, enriches selected events with approved target-system context, and forwards only actionable payloads. It records response identifiers and sends rejected or incomplete events to an operational review path.

Martini capabilities used
  • workflow orchestration
  • API consumption
  • data transformation
  • business rules
  • conditional routing
  • operational error handling

Pattern 4: Build a Proofpoint reporting dataset

When to use this pattern

Use this pattern for compliance reporting, operational metrics, user-level risk analysis, and historical trend reporting. It is suitable for periodic extraction of selected Proofpoint resources into an approved SQL or reporting store.

Integration direction
Proofpoint
Martini
PostgreSQL
Example Mapping
Proofpoint FieldCanonical FieldTarget Field
messageIdemail.messageIdmessage_id
useremail.useruser_identifier
eventTimeemail.eventTimeevent_timestamp
threatTypeemail.threatTypethreat_type
Martini implementation pattern

Martini schedules incremental retrievals, maps Proofpoint resources to a reporting schema, preserves selected unknown fields where appropriate, and performs idempotent inserts or updates. The workflow handles late events through overlap windows and records processing metrics for auditability.

Martini capabilities used
  • scheduled workflows
  • incremental synchronization
  • data mapping
  • SQL integration
  • deduplication
  • monitoring

Applications commonly integrated with Proofpoint

Proofpoint data can be routed through Martini to security monitoring, case-management, identity, collaboration, and reporting products. The exact endpoint, permissions, and event coverage should be validated for the customer’s Proofpoint product and tenant.

Application Scenario Direction Martini Pattern
Splunk Centralize Proofpoint threat, message, and click events for security monitoring, correlation, dashboards, and retention. Proofpoint → Martini → Splunk A scheduled Martini workflow polls Proofpoint SIEM endpoints, normalizes event categories, applies deduplication, and submits batches to Splunk through its supported ingestion interface.
Microsoft Sentinel Send Proofpoint security events to Microsoft’s cloud SIEM for analytics, alerting, and incident management. Proofpoint → Martini → Microsoft Sentinel Martini retrieves incremental Proofpoint events, maps severity and identity fields to the Sentinel ingestion model, and retries transient downstream failures.
IBM QRadar Ingest Proofpoint events into an established SOC monitoring and correlation environment. Proofpoint → Martini → IBM QRadar A workflow polls Proofpoint event endpoints, converts payloads to the target event format, and routes malformed or rejected events to operational review.
ServiceNow Create security incidents or cases from selected Proofpoint threats and maintain operational ownership. Proofpoint → Martini → ServiceNow Martini polls high-severity threats, applies deduplication and routing rules, creates or updates ServiceNow records, and stores correlation identifiers for subsequent processing.
Microsoft 365 Correlate Proofpoint email-security events with Microsoft 365 users, mailboxes, and message context. Proofpoint → Martini → Microsoft 365 Martini combines Proofpoint user or message data with approved Microsoft Graph lookups, applies tenant-specific matching rules, and exposes a normalized security dataset.
Google Workspace Reconcile Proofpoint-protected users and email activity with Google Workspace identity and mailbox administration. Proofpoint → Martini → Google Workspace A scheduled workflow retrieves Proofpoint users or message activity, matches identities against Google Workspace data, and writes exceptions for unresolved users.
CrowdStrike Falcon Combine Proofpoint email threats with endpoint detections for investigation and response. Proofpoint → Martini → CrowdStrike Falcon Martini normalizes Proofpoint threat indicators, enriches them with approved endpoint context, and conditionally forwards related events to response workflows.
Jira Service Management Convert selected Proofpoint alerts into tracked security or IT work items. Proofpoint → Martini → Jira Service Management A polling workflow filters Proofpoint events by severity or campaign, maps them to Jira fields, and maintains idempotent issue creation using Proofpoint identifiers.

How to build a Proofpoint integration in Martini

Objective

Establish access to the specific Proofpoint product and API family required by the integration.

Instructions in Martini

  • Confirm the enabled Proofpoint product, API resources, tenant entitlement, and permissions.
  • Create the API principal and secret or other product-specific credentials.
  • Store credentials in Martini secrets or environment configuration.
  • Configure HTTPS API access without embedding secrets in workflows.

Objective

Select a retrieval model that matches Proofpoint’s confirmed capabilities and the target latency requirement.

Instructions in Martini

  • Prefer a scheduled workflow for documented SIEM and event-retrieval APIs.
  • Use product-specific callbacks only when Proofpoint confirms them for the required event type.
  • Set a polling interval that respects endpoint rate limits and event-window constraints.

Objective

Retrieve Proofpoint resources or event batches reliably and incrementally.

Instructions in Martini

  • Read the last successful timestamp, cursor, or event checkpoint.
  • Request bounded pages or time windows from the applicable REST endpoint.
  • Parse JSON responses and retain the Proofpoint identifiers needed for idempotency.
  • Account for late-arriving events with a controlled overlap window.

Objective

Coordinate retrieval, normalization, routing, persistence, and downstream delivery in a maintainable Martini workflow.

Instructions in Martini

  • Separate authentication, retrieval, transformation, business rules, and delivery stages.
  • Process each event category according to its available fields and destination requirements.
  • Persist checkpoints only after all required downstream writes succeed.
  • Route unrecoverable records to an operational review or dead-letter process.

Objective

Convert Proofpoint resources into canonical enterprise security models and target-specific payloads.

Instructions in Martini

  • Map messages, threats, clicks, campaigns, users, and attachment metadata explicitly.
  • Preserve stable vendor identifiers and relevant timestamps.
  • Handle optional fields and product-specific schema differences.
  • Apply masking or filtering rules to sensitive message, URL, recipient, and attachment data.

Objective

Ensure only relevant and authorized Proofpoint events reach downstream systems.

Instructions in Martini

  • Filter by severity, threat category, user, domain, campaign, or disposition.
  • Apply allowlists and routing rules before creating incidents or response actions.
  • Use stable identifiers to prevent duplicate incidents and repeated notifications.

Common Proofpoint data objects used in integrations

ObjectTypical UseCommon target systemsMartini handling
MessagesRepresent inbound or outbound email activity, delivery or blocking information, message identifiers, and threat-related metadata.SIEMs, SOAR platforms, ServiceNow, Microsoft 365, Google Workspace, reporting databasesMartini retrieves message data through the applicable REST or SIEM endpoint, normalizes optional fields, applies idempotency rules, and forwards approved content.
ThreatsRepresent malicious or suspicious artifacts detected through Proofpoint threat-protection products.SIEMs, SOAR platforms, ServiceNow, Jira Service Management, security data lakesMartini filters by severity, campaign, user, or disposition, enriches and transforms the payload, and creates or updates downstream security work.
ClicksCapture user click activity involving URLs protected or observed by Proofpoint.SIEMs, risk reporting stores, SOAR platforms, security analytics systemsMartini polls supported click resources, deduplicates overlapping time windows, and maps URL, user, message, and timestamp fields to the target schema.
CampaignsGroup related threat activity into campaigns or attack clusters where exposed by the selected Proofpoint product.SIEMs, threat-intelligence stores, reporting platforms, case-management systemsMartini links campaign identifiers to related threats or messages when available and routes campaign-level alerts according to business rules.
UsersRepresent protected users, recipients, or users associated with Proofpoint security events.Microsoft 365, Google Workspace, identity stores, reporting databases, case-management systemsMartini matches Proofpoint user attributes to approved enterprise identities, flags unresolved matches, and restricts sensitive fields in downstream mappings.
AttachmentsProvide attachment-related threat information or metadata associated with messages where exposed by the relevant API.SIEMs, SOAR platforms, security reporting stores, case-management systemsMartini processes available metadata and threat indicators; unrestricted attachment downloading is not assumed and must be validated for the selected product.

Authentication and security considerations

Product-specific credentials

Proofpoint authentication varies by product and API family. TAP APIs commonly use an API principal and secret with HTTP Basic Authentication over HTTPS.

Secret management

Store Proofpoint principals, secrets, and authorization configuration in Martini secrets or environment-managed configuration rather than in workflows or mappings.

Least privilege and data protection

  • Scope API permissions to the required Proofpoint products and resources.
  • Do not log credentials, authorization headers, or unnecessary message content.
  • Protect threat, recipient, URL, and attachment metadata according to enterprise privacy and retention requirements.
  • Validate permissions and endpoint availability in the customer’s Proofpoint tenant before production deployment.

Operational considerations for Proofpoint integrations

Rate limits and pagination

Confirm endpoint-specific rate limits, page sizes, result limits, and time-window rules. Use bounded polling, controlled concurrency, and exponential backoff for throttling and transient server errors.

Checkpoints and idempotency

Persist timestamps, cursors, or event identifiers only after downstream processing succeeds. Use overlap windows for late events and stable Proofpoint identifiers to prevent duplicate delivery.

Schema and product variation

Proofpoint fields vary across TAP, SIEM, TRAP, Essentials, and other products. Treat payloads as external schemas, preserve useful unknown fields where practical, and handle optional message, user, URL, and attachment data.

Monitoring and testing

  • Monitor polling delay, event volume, duplicate rates, failed deliveries, and checkpoint progress.
  • Separate authentication, authorization, throttling, malformed-request, and downstream failures.
  • Test representative event categories and product-specific permissions before production release.
  • Route unrecoverable events to an operational review process.

Why use Martini instead of scripts or point-to-point integrations?

Centralized orchestration

Martini coordinates Proofpoint retrieval, checkpointing, transformation, business rules, downstream delivery, and error handling in an explicit workflow rather than scattering logic across scripts.

Reusable integration logic

Teams can expose normalized APIs, reuse mappings and validation logic, and route the same Proofpoint event model to SIEM, SOAR, case-management, and reporting targets.

Operational reliability

Martini supports scheduled execution, controlled retries, idempotency patterns, environment-managed secrets, and workflow observability for long-running security integrations.

Maintainability

API-specific differences and evolving Proofpoint schemas can be isolated in mappings and workflow stages, making changes easier to test and deploy than separate point-to-point scripts.

Frequently asked questions

How can Proofpoint be integrated with enterprise systems?

Proofpoint can be integrated through its documented REST APIs, including TAP and SIEM-oriented resources for threats, messages, clicks, people, and related event data. The common enterprise pattern is scheduled API polling with pagination or bounded time windows, checkpointing, deduplication, transformation, and delivery to SIEM, SOAR, case-management, reporting, or database platforms.

Can Martini integrate with Proofpoint?

Yes. Martini can integrate with Proofpoint by consuming its documented REST APIs and polling supported SIEM endpoints from scheduled workflows. Martini can authenticate, retrieve and normalize Proofpoint data, apply business rules, maintain checkpoints, and deliver results to downstream systems.

Do I need a connector to integrate Proofpoint with Martini?

No. A dedicated Proofpoint connector is not required. Martini can use Proofpoint’s confirmed native integration mechanisms, particularly REST APIs, SIEM event-retrieval endpoints, and product-specific authentication. Webhooks should not be assumed unless Proofpoint confirms them for the required product and event type.

Is there any extra Lonti cost to integrate Proofpoint with Martini?

Lonti does not charge an additional per-connector or per-vendor fee to integrate Proofpoint. The integration is subject to the provisioned capacity of the Martini environment. Separate costs may apply from Proofpoint, cloud infrastructure, SIEM platforms, or other third-party systems based on subscription, usage, and deployment model.

Which Proofpoint integration methods should be used?

Use the Proofpoint REST APIs documented for the customer’s product and entitlement. TAP and SIEM-oriented APIs are the primary mechanisms for retrieving threats, messages, clicks, people, and selected event categories. GraphQL and SOAP were not confirmed, and a universal bulk export or general-purpose webhook mechanism should not be assumed.

Are Proofpoint events available through webhooks or callbacks?

A general product-wide Proofpoint webhook or callback mechanism was not confirmed. The documented SIEM pattern is generally scheduled REST polling. Product-specific notifications may exist, but they should be verified with Proofpoint before designing a push-based integration.

How does Proofpoint synchronization handle mapping, duplicates, and failures?

Martini can map Proofpoint resources into canonical and target-specific schemas, persist timestamps or cursors, use overlap windows for late events, and deduplicate using stable Proofpoint identifiers. Workflows can retry transient throttling or server errors, separate authentication and authorization failures, and advance checkpoints only after successful downstream processing.

Can Martini expose a Proofpoint API façade?

Yes. Martini can expose a REST API that returns normalized Proofpoint threat, message, click, campaign, or user data to internal applications. The façade can centralize authentication, filtering, transformation, business rules, and access control while retrieving data through the customer’s authorized Proofpoint APIs.

Related Martini documentation

API Workflows

Data Processing

Security

Operations

API Exposure

Connect Proofpoint with Martini

Use Martini to build reliable Proofpoint API integrations that synchronize security events, automate incident workflows, and expose normalized data to enterprise applications.

EXPLORE MARTINI
BOOK A DEMO