We would like to connect and fetch data from the Google Ad Manager API. Since there is no dedicated Matillion component for this purpose we have created an API Profile and would like to realize the authorization by using OAuth2.0. So far we have tried to pass the OAuth parameters by specifying those in the Parameter section as you can see in the attached screenshot "api_profile.png" but it failed due to a failed authorization (also visible in the attached screenshot).
Do you have any idea why it's failing or concrete tutorial that explains how to connect to the Google Ad Manager API?
Thanks in advance.
Best regards, Gökhan
8 Community Answers
Goekhan Cimsir —
Unfortunately I could not find any option to attach files. If you need the metnioned attachments from my previous post please provide me an E-Mail address or any other option.
Thank you for your response and for highlighting the relevant documentation.
Although we've studied your referenced documentation we are still getting failures when connecting to our Google Ad Manager API.
Specifically we do not understand if we have to implement the OAuth2.0 flow manually when we want to create and connect to a custom API Profile.
One way we were thinking of is just to put the OAuth2.0 parameters such as OAuthClientId and OAuthCliendSecret in our custom API profile parameters but this did not work since it results in an authorization failed error response.
On the other hand we could try to create different rsd-files in our API-Profile that could deal with the single steps of an OAuth2.0 process such as
1. requesting the auth code 2. exchanging code for token etc.
The third option we can think of is to somehow link our API profile with the Matillion Manage OAuth configuration but here we would not know how to do so.
Is there any recommended way to authenticate/authorize a custom API Profile with OAuth2.0.
Matillion’s API Query component does not support OAuth in a single operation. Instead two steps are necessary:
You call the API’s authorization endpoint, provide the ClientId and the Secret, and receive back a bearer token.
You use the bearer token when calling any of the ordinary API endpoints.
Our document on Obtaining an API token and passing it into a RSD script has an example which you can download and install into your own environment in order to take a closer look at how those two steps could be implemented. It’s not specific to Google Ad Manager but does demonstrate how to split the problem into two parts.
Thank you for the referenced example. But even by following it we did not manage to authorize successfully with the Google Ad Manager API. In the example there seems to be a missing step at the beginning of the OAuth Flow that is required to correctly authorize with Google API.
In the first step it is needed to request an Authorization Code that is later exchanged for a Bearer Token by calling the /token endpoint as described here (Step 1: Set authorization parameters):
In order to authenticate/authorize with Google Ad Manager it is required to apply the OAuth 2.0 Authorization Code Grant type. Thus the first step is to request an authorization code that is later exchanged for the actual Bearer Access Token. In your mentioned url the request goes directly against the token endpoint. In our scenario this is possible in exchange for an authorization code that needs to be requestsed first.
Consequently the first step I would like to realize with Matillion API profiles is to make a request for the Authorization Code. The problem is that the requested URL returns an HTML page with that the user must interact by for instance pressing a button in order to allow the application to access the required (defined as scope) resources. When the user accepts this an authorization code will be returned. And this code is exactly what I need to send to the token endpoint of the Google Ad Manager API in order to get a valid token.
I will send you an E-Mail to email@example.com how the RSD file looks like and screenshots where you can see the error. As far as I can understand the returned result cannot be mapped to the expected output (column code) defined in the rsd file which is quite normal since the returned format is an HTML page that usually needs user interaction.
From what I have seen with OAuth, the 1st step always requires manual intervention – hence the login page. This first step should result in some token which will then allow you to automate the process of token refreshes and subsequently access to data.
However, the tokens generated as such will expire after certain period(?) of inactivity. In this case, you will have to start at Step1 again.
If this is a server-to-server process, tokens will be refreshed (step2) at regular intervals (daily?) to keep them valid.
I have in the past used Google OAuth playground to generate the necessary tokens in step1. This would involve logging into relevant account and then Authorising that account. Then use the generated tokens to automate my process and it ran pretty well for the period I tested (1 month).