Unable to create POST Endpoints

[Sara_Melo]

I’m having issues creating a POST method inside the Endpoint Experiences.

I’ve following this documentation:

Part 3 - Device Registration

I’m able to create a GET endpoint and connected to the workflow where it provides the dummy response back but as soon as I change it to POST and attempt to POST to it I get:

{

"error": "No endpoint found for route"

}

If I keep it as a GET endpoint I am able to use any method to the endpoint but the workflow registers it as a GET.

Would appreciate any insight on this. I do have it as a PUBLIC Endpoint for testing since it doesn’t think it exists anyways.

[JuliaKempf]

Hi @Sara_Melo,

Welcome to the Losant Forums! Just a few basic questions to begin debugging, have you created the Experience Endpoint and is it set up with a POST method? If so, is the Endpoint enabled? Is the Endpoint Node in the workflow configured for the POST method (example below)?

Thanks so much,
Julia

[Sara_Melo]

Hi @JuliaKempf ,
Thanks for the response.
It is enabled, and attached to the workflow as your image shows. If I change it to a GET, I do get a response so I know the workflow is setup properly. It just always responds with error if I try to create anything but GET methods.

[JuliaKempf]

Hi @Sara_Melo,

Could you possibly provide your application ID and workflow ID? I will message you privately, but this way I can look further and deduce whether or where the problem lies in Losant.

Thanks!
Julia

[Sara_Melo]

Hi @JuliaKempf,
I messaged you the link. Thanks for the help.

[Tim_lamborn]

I have just run into this issue.
What was the fix for this?

[Heath]

Hi @Tim_lamborn,

Would you be able to share a screenshot of your endpoint configuration or some more information about how you are creating a POST endpoint for your Experience?

If you are creating a GET endpoint, and then turning it into a POST endpoint, then I would make sure that you have updated the endpoint configuration to be a POST, and that your endpoint is enabled:

Once you make this change, you will have to click “Save Endpoint” at the bottom of the screen.

Then in the workflow, double-check to make sure that the Endpoint Trigger is referencing the correct Endpoint:

Note that the label of my Endpoint Trigger is GET /test because this workflow was created when I created the GET endpoint.

How are you making a POST request to the endpoint? Are you using a tool like Postman?

Any additional information you can include will be very helpful.

Thank you,
Heath

[Tim_lamborn]

Thanks @Heath,

I have created a custom experience endpoint, configuration below:

This is handled by a workflow with the following node:

The Endpoint node never triggers the debug statement directly below it.
The workflow is 609b2db7bd1ac30006e1b563, the only one in the application. Feel free to take a look or try hitting that endpoint yourself - it only triggers a debug node.

I have been using Postman to test this endpoint.
Let me know if I can provide any further information

[Heath]

@Tim_lamborn,

Thanks for sending along that info!

I was able to successfully make a POST request to your endpoint with Postman. I here’s the configuration I used in Postman:

As you can see I’m sending a long the JSON body of

{
    "hello": "world"
}

And in your workflow:

Would you be able to share a screenshot of your Postman configuration?

Thank you,
Heath

[Tim_lamborn]

Oh dear…

Thanks for your examples. After playing spot-the-difference I realised I hadn’t specified https://.
Once I did that everything just started working as expected.

Thanks for the support.

[emcdee]

In fact I’m getting ‘authorization required’ … after apparently following all above steps
(and Losant-U’s video using bearer token);

[Dylan_Schuster]

First thing that comes to mind: Is that token associated with your Losant user account or an Experience User account? Losant user tokens are not valid for requests to Experience Endpoints; it has to be an Experience User’s token.

If that’s not the issue, we’ll need additional information to figure out what’s going on here - the Losant application ID, the configuration for your POST /api/devices endpoint, etc.

[emcdee]

Copy that, good suggestion and yes;
using the Experience user api based on Losant-U video,
login to ‘Kanarra’ >> browser inspect > application > cookies > losant.token

So generally:

• Did the bootstrap API endpoint, using authorization; here’s the results:
  (yes, it’s a POST)
  

• Goes to a POST workflow
  

  

• Which comes from the former Endpoint
  

• There is (only 1) test.user
  

• Who’s logged into ‘Kanarra’
  

  

• Who’s token we’re using…
  

• …in the PostMan test (using ‘bearer token’ as shown in video), pic above;
  (API url = https:// + [app address] + [route above])

Else I msg’d you the app address
Thanks

[emcdee]

FYI,
I’ve also tried the url param for auth; doesn’t seem to work either…

• First, as shown in Losant-U video:
  

• Then as docs say to do:
  

Noting, both are POST types to https://[appName]/api/devices…

[Dylan_Schuster]

losant.token is your Losant user’s cookie - not your Experience User’s cookie.

Your Experience User’s cookie is under whichever name you assigned to the cookie when replying to a successful login request. In most cases it is ‘authorization’.

[emcdee]

Well son of a nutcracker…
Yea, I mistakenly used losant.token vs authorization cookie.

That said, ‘auth’ token changes when the same Experience user logs into ‘Kanarra’ on different PCs, so I didn’t know how to compare.
Actually, if APIs (Endpoints, not an Experience page) are getting HTTP traffic from different sources, would you have to utilize user / pword auth (of the Experience user) in url query string params no? That didn’t seem to work either (my other screenshots above, and pattern below).

On the flip side for losant.token (from cookies when an Experience user logs into ‘Kanarra’), are you saying that is similar to how a Losant user generates a token in app GUI at bottom of sidebar? I take it losant.token is supposed to be more ‘global’ for the Losant RESTful API (permissions controlled by Losant vs Experience user).

[emcdee]

Quick adder…

Query string params not so secure (for user / pass), even in https://
And you could do basic auth (like header), but that doesn’t really seem to be SSL either.

Though I see the format “?authorization=[token]” works well as suffix; but like above, wondering what easy method to get an auth token for an Experience user that doesn’t log into a web interface.

[Dylan_Schuster]

That said, ‘auth’ token changes when the same Experience user logs into ‘Kanarra’ on different PCs, so I didn’t know how to compare.

Correct, if you sign in as the same user on two separate devices, that will generate two valid auth tokens for that user (unless you are specifically invalidating all tokens when issuing the second one). That is pretty standard for web applications.

Actually, if APIs (Endpoints, not an Experience page) are getting HTTP traffic from different sources, would you have to utilize user / pword auth (of the Experience user) in url query string params no? That didn’t seem to work either (my other screenshots above, and pattern below).

I would recommend passing an authorization header in your requests with the value of “Bearer USER_AUTH_TOKEN”, and you can pull that token from the authorization cookie. Though it too is encrpyted over https, the query string exposes the token in plain text to anybody who sees the browser bar and also in any server logs. This article covers the topic well.

If you need a little more guidance on how to set the auth token in a cookie and utilize it in asynchronous requests to an experience API, I recommend checking out the React.js Boilerplate template.

On the flip side for losant.token (from cookies when an Experience user logs into ‘Kanarra’), are you saying that is similar to how a Losant user generates a token in app GUI at bottom of sidebar?

losant.token is issued by accounts.losant.com when you sign in, and we issue the cookie with the domain property of “losant.com”. Since “app.losant.com” (the user interface) and “api.losant.com” (the API root) share the same root domain, and since we issue the cookie with that “domain” property, the cookie is expose to those subdomains. (You can read more about this here.)

The reason you are seeing losant.token show up when looking at your experience is because you are loading in a Losant dashboard through a Dashboard Experience Page. If you view the page source, you’ll see that scripts pulling from app.losant.com are in the markup - and by loading these scripts from that domain, your browser is making the cookie available.

I take it losant.token is supposed to be more ‘global’ for the Losant RESTful API (permissions controlled by Losant vs Experience user).

The cookie from losant.token can only be used to authenticate requests as your Losant user account against the Losant API. The Experience User has no permissions to access the Losant API directly; rather, that token (the authorization cookie) authenticates against your experience endpoints only.

[emcdee]

Many thanks indeed for all the clarifications and links.