As documented here and here once I obtain my "code": "<THE_AUTHORIZATION_CODE_YOU_WERE_GIVEN>" after hitting the authorization endpoint with the proper payload (which I have done, and this payload requires the redirect_uri) I then want to call the obtain token endpoint.
My call is like so:
r = requests.post(
url='https://connect.squareupsandbox.com/oauth2/token', # dev
headers=SQUARE['HEADERS'],
data={
"client_id": SQUARE['APP_ID'],
"client_secret": SQUARE['APP_SECRET'],
"code": authorization_code,
"grant_type": "authorization_code"
}
)
this is using standard Python requests lib and mirrors the documented payload (copying from Square docs):
i also validate the same error in my terminal using curl explicitly matching documented payload, substituting in my correct authorization_code by pulling it from my python terminal after printing it from the redirect handler…
so i don’t get it because redirect_uri is not required for this endpoint? and it wouldn’t make sense here?
I’m Square Dev AI, here to help answer your question!
Based on the information you’ve provided, the following documentation will help answer your question:
If this documentation helped you find a solution, please check the box indicating that this reply solves the problem.
Otherwise one of our Developer Advocates will provide additional assistance shortly.
I took a look at the account and see that your configured redirect URL isn’t HTTPS which is a requirement. If you update it to an HTTPS URL does it work as expected?
but this isn’t an endpoint that requires that? i already got it to work with that redirect_uri for the refresh handler, this is a dev account so yes i am not using https for my redirect_uri in either dashboard or any param… that doesn’t change the fact that
a). redirect_uri is not required for this endpoint
b). i already successfully got the redirect_uri to work from a non https redirect because this is dev… if it hadn’t worked i would not have the authorization code to obtain the token…
am i missing something? it seems like a key API is improperly documented…
tbh like not to be salty but i would expect square to have a better response, you guys dominate the POS space and have an active dev marketplace how is it so poorly documented… examples:
you use interchangeably “redirect_uri” in API docs but in the dashboard mention “redirect url” which i presume is the same thing, there is already another thread in this forum about this confusion stemming from basic failure to adhere to naming conventions.
you are telling me I have an error that is not relevant because a). it is earlier in the oauth handshake/flow, and it already worked b). this is a sandbox account, so no https should not/is not required c). if the “redirect” part of this wasn’t working, i would never have gotten to this step anyway…
my question is pretty simple why is this endpoint complaining about this:
note state is just a random token for csrf protection, as documented here…
also note the redirect_uri is working…
so i get the code from this, but then as I’ve said when I post to this endpoint using the authorization code returned from the redirect after hitting that url you asked me for, that subsequent post to obtain token is complaining about the redirect_uri… when it is not required…
Configuring a redirect_uri in the URL is only a requirement for PKCE. Since you have the URL configured in the Developer Dashboard it will automatically redirect. From there when calling ObtainToken with the code it will work as expected.
like i get that u have two flows side by side (which imo is already ripe for confusion, u should have separate pages for the two flows if it is going to be written with this level of precision) but the way the docs are organized where if i’ve already decided on my oauth strategy every page documenting the flow has both ways on it, and then the API for one strategy is accepting my redirect_uri param without error (even though it was meant for the other strategy??) and even though it is the same as the one in my dashboard… and this causes it to then weirdly fail on the obtain endpoint that doesn’t even require it…
it just really seems like u could improve the docs for a relatively low lift on your side and save a lot of devs reading it a lot of time… but thank you for getting it working, thanks again just like no one wants to be stuck on an authorize step, but thank you!
like this is just bad documentation like i understand the “mistake” i made but it just really seems like combo of poor docs or just some bug on the obtain endpoint… so thanks again but it would be nice if the support team took some responsibility or initiative re: the docs being unclear… i think most devs working against an API would prefer to rely on clean docs and not needing a back and forth on a forum to manage what should be a simple oauth handshake… if redirect_uri breaks the non PKCE flow here that should be mentioned explicitly…