Skip to main content

The below image is the documentation for my endpoint. I can't get this to work. 

When I configure this in the portal I get back a 415 error. 

Any general guidelines on how to configure this?

 


Update 2024-07-22


The regular way:

I’ve been doing some additional testing. Here's a more detailed description of my findings/problems. 

The API wants to receive a JSON body like so:

{

"grant_type": "authorization_code",

"code": "abc***123"

}

I tried to add fill out the portal like this:

This doesn't work and returns the 415 error.

What should I fill out in stead?


 

My cicumvention (doesn't suffice).

 

I configure one endpoint (access_token) to be a POST request (the request that will give back my bearer token). I then configure a second endpoint (Products) and use a dynamic value based on access_token and use it in the header Authorization. See images below.

A POST request that will return my bearer token.
A GET request that uses the bearer token value returned by the previous endpoint.

This method does “work” but is not sufficient. The Products endpoint returns exactly the data it should, but this is as “deep” as I can go. 

The reason this is not sufficient is that I need another endpoint that should dynamically use values from the Products endpoint. The limitation here is that there can be only one dynamic values source. So I can't use both the values from Products and the bearer token returned by access_token. So here the workaround has reached its limits. This could be fixed by adding a feature that allows one to use multiple dynamic values sources. 

Hi @Benny 

Can you please share a link to the REST API documentation?


@Christian Hauggaard, sure: https://synf.co/restapi


@Christian Hauggaard, sure: https://synf.co/restapi


@Christian Hauggaard, I made an update to the post. Hope it will provide some clarity. 


Hi @Benny 

Can you please share what settings you have tried for your REST data source? 

Have you tried both the Cdata REST data source and the TimeXtender REST data source?

For the TimeXtender REST data source, did you try the 2 below options?

 


I also tried the OAuth refresh token option: 

I also have set 

hoping that would be the fix for the 415 error, but sadly that doesn't help.


Hi @Benny 

Please try the following parameters/properties, please replace the initial access token with a valid token 

 


Hello @Christian Hauggaard, these settings work. Thank you for that. 
 

Just to get the complete picture:

  • The refresh token will be updated with a call that is after 604800 seconds after the initial creation timestamp? Or after each call? 
  • This is all hashed and saved in the file OauthWorkingData.json in the directory I specified?
  • And the create timestamp will be updated?
  • Is there a counter somewhere that counts the multiples of 604800 that have expired since the create, or is this calculated on the spot?
  • And if tokens and or anything else are updated, can I see the changes in the portal?

Hi @Benny 

Please see answers below

  • The refresh token will be updated with a call that is after 604800 seconds after the initial creation timestamp? Or after each call? 
    • Yes, the token will be refreshed when it has expired.
  • This is all hashed and saved in the file OauthWorkingData.json in the directory I specified?
    • Technically it is encrypted, not hashed, but yes it is stored there. 
  • And the create timestamp will be updated?
    • Do you mean the initial access token created timestamp? If so, no. That is only used for getting the first token. 
  • Is there a counter somewhere that counts the multiples of 604800 that have expired since the create, or is this calculated on the spot?
    • There is no counter. 
  • And if tokens and or anything else are updated, can I see the changes in the portal?
    • No these changes are not visible in the portal

Hello @Christian Hauggaard

 

I'm still having problems with this connection. The bearer token expired and it looks like TX is unable to refresh properly. 

 

I get the following error:

It seems like the request is somehow badly formed based on the input I gave (which is like in the above conversation). The error code is 415 (Unsupported Media Type). 

It seems like it isn't using the Content-Type header (but that's just my hunch). I think this because I tried to deliberately give a faulty parameter (ie misspelling one) in the portal. This should give me a 500 error since this is the response for an ill-formatted json body, but it still returns the 415. Leading me to conjecture that it is indeed a fault in the way the connector formats the POST request for refreshing (perhaps not actually creating a json?). 

 

Let me know if you need any additional info.

 

Kind regards,
Benny Aalders


Hi @Benny 

Can you please share all your data source settings related to the products endpoint?


Hi @Benny could you please provide an update on the above?


Hello @Christian Hauggaard, I've been in contact with Thomas Lindt for a solution.

The problem appeared to be that the API is just not accepting Content-Type = x-www-form-urlencoded, which is what the portal is configured to send. I made a feature request to also be able to send a raw body with application/json via Thomas.

I also send a feature request to the API developers (of the data source) to just accept x-www-form-urlencoded, which they said they will do. I expect that will solve my problem. Consider this problem solved.

 

Thank you for helping. 


Reply