Extra information on redirect_uri

API Q&A
1

Hi. We have a multi-tenant application in which we are building support for using the InfusionSoft API. The different customers, on our side, are differentiated by subdomain. So, we have things like
wndr.wearehearken.com

…

Would love to have kalw.wearehearken.com/oauth/callback and wndr.wearehearken.com/oauth/callback, but since we only can have a single registered redirect_uri for the oAuth flow, it seems like I need to build something like:
oauth_callback.wearehearken.com/callback

which will be redirected to after going through the “Request Permission” part of the flow for all our customers. Unfortunately, I need to be able to track which customer this was for in order to save the token for them. Help.

My initial thought is to pass a query param on the redirect_uri. So, I’d register
oauth_callback.wearehearken.com/callback
with my infusionsoft app, but when I redirect to
https://signin.infusionsoft.com/app/oauth/authorize
I would add on a query param like
https://signin.infusionsoft.com/app/oauth/authorize?orgslug=kalw
https://signin.infusionsoft.com/app/oauth/authorize?orgslug=wndr

Is there a way to have this passed back when redirecting back?

Or, is there a preferred way to do this from the InfusionSoft perspective?

2

This isn’t something that you’ll want to “piece” together. A system like this would be best served by maintaining token and customer domain information in a database on your server and then authentication, management and redirections would be under your control

3

Yes, we do keep all this in our database. The issue, though, is that our InfusionSoft app can only have a single redirect uri registered (unless I’m misunderstanding, since, on the “Edit Application” form, it only has a single field for the “Register Callback URL”.

So, all our different clients would be authorizing with our “Hearken Integration” app that is registered with InfusionSoft. With a single callback url, I need to have a way to have the callback redirect uri say “this is who we are authorizing”.

Alternatively, I guess I could call back to get the token (using the code), get user information and somehow key off of that to figure out which of our customers it is.

4

So, in the end, I just need some sort of id that I generate that is passed along through the oAuth flow.

5

@Corey_Haines we do not enforce the registered redirect_uri, so you can use whatever redirect uri or uris you want. You will have to make sure you use the same redirect_uri for obtaining an authorization and exchanging that authorization code for an access token.

The query string issue is a known issue and we have had an open ticket with our vendor Mashery for a couple weeks now. Hopefully they get it fixed soon. By spec any query string you send via the redirect_uri needs to be included in the final redirect along with the authorization code. I will try to remember to post back here when the issue is resolved.

6

So you’re just talking about the OAuth token process. Yes, i’ve used a completely different domain to receive tokens as a return so it will work to do so.

7

Oh, that’s wonderful news! I totally misunderstood the documentation. Thanks so much. We definitely be keeping the same domain across the different calls in one flow. I’ll be working on this over the next two days, so I’ll post back and close when I get it working.

Thanks again for the prompt responses!

8

So, I’m using a different URL, and (at least when doing it manually with curl), things are working. Thanks so much for the help!
Having trouble with the refresh token call returning invalid_client, but that’s a separate issue. :slight_smile: