My POST requests work fine, to the /decode endpoint. But to any of the GET endpoints wihtout a doubt I get back “message:Error : Service Id / Credentials authentication failed”.
for the v2/campaign/ids endpoint you have to both use basic auth creds AND service app auth?? The POST endpoints work just fine using only basic auth…
You need to include a filter. e.g. /v2/campaign/ids?interval=2020-12-08T00:00:00Z/2020-12-09T00:00:00Z&page=1&size=100 this route with the same connector as the POST worked for me in the HTML Plugin
I got the auth error without the filter even in PowerShell
Parameters
Required Parameters
interval
A string containing an ISO8601-formatted interval. The minimum interval is 30 seconds. The maximum interval is 1 day.
Examples:
2020-05-01T12:00:00Z/2020-05-01T13:00:00Z - an hour interval, beginning at noon UTC on 05-01-2020
PT30M/2020-05-01T12:30:00Z - the thirty minutes beginning at noon UTC on 05-01-2020 and ending at 12:30pm UTC
2020-05-01T05:00:00-0700/PT30M - the same interval as above, but using -0700 as the time zone
Optional Parameters
size
The maximum number of campaign IDs to produce in the response. Defaults to 100 and the max supported value is 200.
page
The page of results to return, in multiples of the specified size (or 100, if no size is explicitly chosen). Defaults to 1.
using this route /v2/campaign/ids?interval=2020-12-15T6:00:00Z/2020-012-15T13:00:00Z&page=1&size=100
and same connector as POST but getting same 401 error. Why you no work Proofpoint?!
What happens when you specify a specific ID, e.g. /v2/campaign/<campaignID> with the same connector as POST (Also, make sure you are using the GET actions for both of these)?
If you are still getting a 401 the issues is probably in permissions on your TAP instance
Maybe that is why, I am using a header {“Authorization”: "Basic <Base64 encoded UserName:API Key>"} for my header for all my POSTs and GETs and this works fine in the HTTP Plugin with the Campaign route.
I think that is the same thing, but check your formatting of your header
{“user”:“principal:secret” } isn’t the right format I don’t think, it needs to be {“Authorization”: "Basic <Base64 encoded principal:secret> "}
That is how I’ve always formatted basic Auth and it is working for me in the plugin
Thanks Brandon. Still getting that lovely error 401… pulled enough hair out for one day. But I am encouraged that you are getting it to work for yours.
So, just to be safe, I created a new connection using the current HTTP Requests Plugin and this time used the basic auth built in with username=principle and password=secret and it still worked. this would be the better way to do this just had the header prebuilt before so that is why I did it that way. But I just proved that both worked. So I really don’t think this is an InsightConnect issue.
If you are on a Windows box can you try this PowerShell? $TapPrincipal = '<principal>' $TapSecret = '<secret>' $TapBaseURL = 'https://tap-api-v2.proofpoint.com/v2' $TapApiKey = "$($TapPrincipal):$($TapSecret)" $TapEncodedCreds = [System.Convert]::ToBase64String([System.Text.Encoding]::ASCII.GetBytes($TapApiKey)) $TapBasicAuthValue = "Basic $TapEncodedCreds" $TapHeaders = @{ Authorization = $TapBasicAuthValue } $TapCampaignURL = "$TapBaseURL/campaign" $TapCampaignResults = Invoke-RestMethod -Uri "$($TapCampaignURL)/ids?interval=2021-01-6T00:00:00Z/2021-01-7T00:00:00Z&page=1&size=100" -Headers $TapHeaders $TapCampaignResults.campaigns
If that doesn’t work, there are permission issues on you TAP side. If that does then either check your network routes or convert it to python and try on the orchestrator.
Another thing is maybe create a whole new connector and test Workflow just to make sure you didn’t fat finger anything.
The good news is that it does work and you can do this with InsightConnect, the bad news is I’m not quite sure why you are getting that error.
well something new… tried that with a new connection. Now I am getting this, which to me just suggests a new auth error expressed differently. Going to test out more today at some point. thanks again for the help.
Also, check your timeframe in the query, I got a 404 when I had 2020-01-06 but a success when i changed it to 2021-01-06
A 404 for and old date range seems weird, but that is what it returned