Proofpoint TAP

Fluency collects Proofpoint Targeted Attack Protection threat events over TAP's SIEM API: the clicks your users made on malicious URLs and whether URL Defense stopped them, and the messages that carried a known threat and whether they were quarantined or reached the mailbox. A permitted click followed by an unusual sign-in is one of the strongest signals in a mail-borne intrusion — and it only exists in the lake if this feed is running.

Authentication is a service credential: a service principal and a secret, presented as HTTP Basic, created in the TAP Dashboard. Fluency polls the SIEM API with it. Nothing is installed in Proofpoint and nothing is pushed to Fluency.

The setup has two halves:

1. In Proofpoint — create a service credential in the TAP Dashboard. This produces two values, a Service Principal and a Secret.
2. In Fluency — install the Proofpoint TAP application template and paste those two values into its form.

There are two Proofpoint templates — this page covers TAP

Template	Proofpoint product	Where the credential is made	Pre-filled API Endpoint URL
Proofpoint TAP (this page)	Targeted Attack Protection	TAP Dashboard → Connected Applications	https://tap-api-v2.proofpoint.com
Proofpoint Essentials	Proofpoint Essentials	Essentials → Account Management → Integrations	https://us-siem.proofpointessentials.com

Both templates take the same three parameters — an API Endpoint URL, a Principal and a Secret — so the credential shape no longer tells them apart. The pre-filled endpoint host does, and it is the fastest check on the form itself.

These are different products aimed at different segments — TAP is the enterprise service that runs alongside Proofpoint's mail gateway, Essentials is the small-business service usually delivered through a partner — and an organisation has one or the other. If your administrators sign in at proofpointessentials.com, you want Proofpoint Essentials.

What arrives

The SIEM API exposes four classes of event, all of them threat-related.

Stream	What it records	Endpoint
Clicks blocked	A user clicked a rewritten URL that URL Defense recognised as malicious and blocked.	/v2/siem/clicks/blocked
Clicks permitted	A user clicked a malicious URL that was not blocked — typically because the campaign was classified after the mail was delivered. These are the events that need a response.	/v2/siem/clicks/permitted
Messages blocked	A message carrying a threat recognised by URL Defense or Attachment Defense, quarantined before delivery.	/v2/siem/messages/blocked
Messages delivered	A message carrying a known threat that reached the mailbox.	/v2/siem/messages/delivered

This is not a mail log. There is no clean-mail volume here and no per-message delivery trail — every record exists because Proofpoint attached a threat to it. That shapes what the feed looks like in practice: low volume, bursty, and legitimately empty for long stretches.

Before you begin

A TAP subscription and TAP Dashboard access. Targeted Attack Protection is a licensed product with its own console at threatinsight.proofpoint.com, also called the Threat Insight Dashboard. If you cannot reach that dashboard, this is not the integration you have — check whether you are running Proofpoint Essentials instead.

An administrative user who can create service credentials. Proofpoint's public documentation names no finer-grained role than that, so treat it as: someone whose TAP Dashboard shows the settings gear and a Connected Applications tab.

Access to the Fluency portal with permission to install applications.

An empty index is not proof of a broken integration

TAP reports threats, so this feed only produces data when Proofpoint has something to report. An organisation with no malicious clicks and no threat-carrying messages in a given window legitimately yields nothing. The check that settles it is the TAP Dashboard itself — see Confirm it is running.

Seven days of history, one hour at a time

The SIEM API serves at most the last seven days, and a single request may cover at most one hour. A collection gap longer than a week is a permanent gap — there is nothing left to backfill from.

Part 1 — Proofpoint

1. Create the service credential

Sign in to the TAP Dashboard as an administrative user, open the settings (gear) icon in the left rail, and select the CONNECTED APPLICATIONS tab. The Service Credentials panel lists the sets that already exist, each with a Revoke link.

Click Create New Credential, name the set after the consumer it is for — ingext-tap is the name Fluency's own onboarding tooling uses, and is a good default — and click Generate.

Give Fluency its own credential set

Do not reuse a pair that another SIEM or a script already holds. Proofpoint does not document whether the 24-hour request throttle is counted per credential or per customer, so a separate set is not a guaranteed way to buy request budget — but it does mean revoking one integration leaves the others running, and the Last Used column on this page tells you which credential is which.

2. Copy the service principal and secret

The Generated Service Credential dialog shows both values.

Copy the secret now — Proofpoint will not show it again

The dialog says so itself: once you close it the secret is not displayed in the interface and is not retrievable. There is no regenerate action — a lost secret means creating a second credential set and revoking this one. Put it in a secrets manager rather than a document, and do not store it alongside the principal.

Value in Proofpoint	Fluency parameter
Service Principal	Principal
Secret	Secret

Click Done. The new set appears in the Service Credentials table with an empty Last Used column, which is how you will confirm later that Fluency is actually calling with it.

Verify before you leave Proofpoint

The credential is usable immediately, and exercising it here costs a minute — where the same error inferred later from an application that installs and collects nothing costs an afternoon.

curl -s -w '\n%{http_code}\n' \
  "https://tap-api-v2.proofpoint.com/v2/siem/all?format=json&sinceSeconds=3600" \
  --user "<service principal>:<secret>"

Response	What it means
200 with populated arrays	The credential works and TAP has recent activity. Continue to Part 2.
200 with empty arrays — "messagesDelivered": [] and the rest	The credential works. TAP simply had nothing to report in the last hour, which for a quiet organisation is the normal answer.
400	The time parameter is malformed or asks for more than one hour.
401	The principal or secret is wrong — usually a truncated paste — or the credential set has been revoked.
403	Authenticated, but not authorised for this organisation's data.
429	The rolling 1800-request 24-hour pool is exhausted. Something else is calling with this credential.
A connection failure	Outbound HTTPS to tap-api-v2.proofpoint.com is blocked from wherever you ran this.

format=json matters in that command. The API's default format is syslog, which answers 204 No Content when there is nothing to report — easy to misread as a failure. JSON always returns the structure, empty or not.

Part 2 — Fluency

Install the Application

Go to Platform → Applications → Install Application From Template and choose Proofpoint TAP from the Email Audit and Protection category. All three parameters are required, and the endpoint is filled in for you.

Parameter	Notes
Principal	The Service Principal from step 2.
API Endpoint URL	Pre-filled https://tap-api-v2.proofpoint.com. Leave it alone — TAP has one API host, and this is it. A value ending proofpointessentials.com here means you are on the wrong template.
Secret	The Secret shown once in the same dialog. Masked once the application is installed.
datalake	Pre-filled managed.
datalake index name	Pre-filled Proofpoint. Two applications writing to the same index name in the same lake will collide, and the second one aborts — and Proofpoint Essentials ships the same default. See the caution below.

The last two sit in the collapsed Advanced Configurations row below the parameters — expand it to reach them.

Leave Name and Display Name at default / Default unless you are installing a second instance, in which case give each one a name you will recognise on the applications list.

Press Install. The application then appears in the Installed Applications view, where its badge reads Running once the pipeline is up.

Check you are on the right template — read the endpoint, not the field list

Proofpoint Essentials sits directly above Proofpoint TAP in the same category, and the two forms now ask for the same three things, in a different order. Nothing on the form stops you filling in the wrong one. A TAP credential offered to the Essentials host is not a credential that host ever issued: the install succeeds, every poll fails authentication, and the index stays empty.

The give-away is the API Endpoint URL the form arrives with. On this template it reads https://tap-api-v2.proofpoint.com; on Essentials it reads https://us-siem.proofpointessentials.com. The field order differs too — Essentials puts the endpoint first, TAP puts it second, between Principal and Secret — but the host is the value to check, because it is the one that decides where the credential is sent.

An earlier version of this page said the give-away was that Essentials has an endpoint field and TAP does not. That is no longer true: both templates have one.

Both Proofpoint templates default to the Proofpoint index

Proofpoint TAP and Proofpoint Essentials ship the same Proofpoint default for datalake index name. An organisation runs one or the other, so this rarely bites — but a partner collecting from both, or anyone migrating between the two products, installs the second application into a name the first already holds. The second install aborts, and the error is a name clash with nothing obviously to do with Proofpoint.

Change one of them under Advanced Configurations before installing rather than after.

Confirm it is running

The application appears under Installed Applications as Proofpoint TAP: Default. Its badge should read Running in green within a few seconds; Aborted in red means the pipeline stopped on an error, and the details panel carries the message.

With recent TAP activity, the first events should reach the lake within roughly 15 to 30 minutes. Once data is arriving, the Data Lake → Search facet selector offers a Default-Proofpoint_TAP_Events configuration, which is the quickest way to see the stream on its own. See Confirm data is arriving.

An empty index past that window is where this integration differs from most. Three checks, in order:

1. Open the TAP Dashboard and look at the same period. If it shows no clicks and no threat-carrying messages either, nothing is wrong — the organisation was quiet.
2. Check the Connected Applications page. The credential's Last Used column should have moved. If it is still empty, Fluency's calls are not reaching Proofpoint at all, which points at the credential or at egress rather than at the data.
3. Only if the dashboard shows events that the lake does not, work through Troubleshooting.

Maintenance

Rotating the credential

There is no regenerate action on a service credential — rotation means replacing the set. Do it in this order so the only gap is the reinstall itself:

1. In the TAP Dashboard, Create New Credential with a new name (ingext-tap-2), and copy the new principal and secret.
2. In Fluency, uninstall the Proofpoint TAP application and install it again with the new pair. Template parameters are read-only after install, so reinstalling is the supported way to change a credential.
3. Back in the TAP Dashboard, Revoke the old set.

Revoking first would break collection before the replacement exists. Because the SIEM API serves seven days of history, a short gap is recoverable in principle — but do not build the plan around that.

Removing the integration

Uninstall the application in Fluency first — the red Uninstall button at the foot of its details panel — so the pipeline stops cleanly before its credential stops working. Then Revoke the credential set on the Connected Applications page, which is what actually withdraws the access.

Troubleshooting

Symptom	Likely cause	Fix
The application shows Aborted shortly after install	Wrong or truncated principal or secret	Re-copy both values, or create a fresh credential set. Confirm them with the curl in Verify before you leave Proofpoint.
Running, index empty, TAP Dashboard also quiet	Nothing to report	Not a fault. TAP only emits events when it detects a threat.
Running, index empty, TAP Dashboard shows events	The credential is not being accepted, or was revoked	Check Last Used on the Connected Applications page. If it has not moved, run the curl — a 401 means the pair is wrong or revoked.
Collection worked, then stopped dead	The credential set was revoked, or someone rotated it without reinstalling in Fluency	Create a new set and reinstall the application with it.
Gaps in the data under heavy use	The 1800-request rolling 24-hour throttle was hit and the API returned 429	Find the other consumer of this credential and give it its own set. Note that clicks/permitted is throttled in a separate pool from the other endpoints.
Events stop appearing after an outage of more than a week	Retention	The API serves at most seven days. That gap cannot be recovered; note it and move on.
Installed, but nothing ever arrives and the credential tests fine	The Proofpoint Essentials template was installed by mistake, or vice versa	Check which template the card names. Essentials has an API Endpoint URL parameter; TAP does not.

Under the hood

Engineering reference — SIEM API endpoints, parameters and throttling

This section describes the mechanics of Proofpoint's TAP SIEM API. Administrators connecting TAP do not need it.

Transport. All endpoints are served from tap-api-v2.proofpoint.com over SSL, GET only, authenticated with HTTP Basic where the service principal is the username and the secret is the password. There is no token exchange and no regional base URL.

Endpoints, all under /v2/siem/:

Path	Returns
clicks/blocked	Clicks on malicious URLs that were blocked
clicks/permitted	Clicks on malicious URLs that were permitted
messages/blocked	Threat-carrying messages that were blocked
messages/delivered	Threat-carrying messages that were delivered
issues	clicks/permitted plus messages/delivered
all	Every click and message relating to a known threat

Time window. Every request carries exactly one of interval (an ISO 8601 interval, minimum thirty seconds, maximum one hour), sinceSeconds, or sinceTime. The maximum reach into the past is seven days and the maximum span per request is one hour, so a collector catching up after an outage walks the window an hour at a time. Overlapping intervals may return duplicate records.

Optional filters. threatType (url, attachment, messageText) and threatStatus (active, cleared, falsePositive; the default returns active and cleared). format selects syslog — RFC 5424, and the default — or json.

Throttling is a simple rolling 24-hour counter: 1800 requests per 24 hours, after which the API returns 429 until the oldest request in the window ages out. Requests to clicks/permitted are counted in a separate pool from every other endpoint, which is what allows that one to be polled more often.

Response behaviour. There is no paging — every event in the requested window comes back in one body, in no guaranteed order, with all timestamps in UTC. In syslog format, an empty window answers 204 No Content; in JSON the structure is always returned even when every array is empty.

References

Proofpoint

• SIEM API — the primary reference for every endpoint, parameter, throttle limit and status code above
• API Documentation — the Threat Insight Dashboard API index
• Threat API — campaign and forensic detail behind the threats named in these events
• TAP Dashboard — where the service credential is created

Fluency

• Proofpoint Essentials — the other Proofpoint template, for the small-business product
• Install Application From Template — every template and its parameters
• Confirm data is arriving
• Email Security integrations — the rest of this category