HELP! Question about connecting to API and submitting data

API Q&A
#1

We’re trying to migrate to Infusionsoft REST API from old code which uses direct http requests. Here is what we currently have

• Desktop application product for end-users. When users activates the application it sends an HTTP request to our .NET API with contact information.

• .Net API gets contact information from HTTP request, then builds an System.Net.WebRequest to https://abge.infusionsoft.com/AddForms/processFormSecure.jsp with contact information in querystring.

• .Net admin website which sends the same HTTP request to Infusionsoft as .NET API, but allows our managers to submit contact info to Infusionsoft manually (instead of desktop application)

We would like to start using your latest API(s) but not sure which product to choose and which API methods to call instead of current code. So we have the following questions:

  1. Which product will you recommend to use so we could replace current requests with new API(s)?

  2. Seems like XML-RPC and REST APIs redirect user to login page to authenticate. We cannot have end-user to sign-in because our desktop app sends an HTTTP request to .net API behind the scenes. Is there any other way to get an AccessToken in the .NET API to be able to use it in API calls?

  3. How to link our business Infusionsoft account with our developer’s Infusionsoft account, so he could use provided client_id/secret_key or he should create his own sandbox account and use it in development and then just replace client_id/secret_key with production values on the server while deployment?

#2
  1. I’m not sure what you mean by product, but if you are referring to XML-RPC or REST, we are actively developing the REST API, and will in the future discontinue the XML-RPC API, so you should use REST for futureproofing.
  2. Regardless of your backend, you always have to gain authorization from the end user first to the data that they have stored in Infusionsoft. We have a manual access code generation method as well, but that’s honestly an even rougher experience than just opening a webview or hosting your authentication on a server.
  3. There is no such link as you describe. It’s completely possible to have two separate Application Keys/Secrets, but each is distinct.
#3

@TomScott hi, maybe the questions was unclear but our end-users do not have any account in Infusionsoft nor any key/secret etc. Currently our workflow is this

  1. When they activate our software it goes into our web application
  2. Which then sends that information through a web form, we just use the URL for the form, for example (this URL is fake): https://xyz.infusionsoft.com/app/form/process/7aa5217c3e9366e2909aa908dasdiouasd
  3. That way we can update the contact record in Infusionsoft for our customers to keep everything organized.

We are basically trying to achieve the same thing via API since you guys never get back to us about the error we have (which I must say is very disappointing case: 01248971).

So basically we are looking to trigger API via Campaign goal and would like to know how to execute it. We want to use a hard-coded key/secret etc and should work as above example.

#4

Any update on this @TomScott?

#5

I’m still not clear on the use-case involved, but I hope this clarifies some things:

  • Only your application should have an OAuth Key/Secret pair, from registering via our key provider.
  • If your users are not individual Infusionsoft account holders, then you should be handling the credential store independently for them, either through your own authentication service or a hosted identity provider (such as Google, Facebook or LinkedIn).
  • If you need to access a single specific Infusionsoft application, you can follow the OAuth flow manually via a tool like PostMan to generate the Access and Refresh Tokens based on the authorization of the owner of that application’s account. You would then need to persist and refresh those tokens on a scheduled bases to maintain them in perpetuity.

You can’t hard-code a key/secret, because that isn’t really how OAuth works. It is intended to require cycling credentials and independent authorization for security purposes.

#6

In other words we can not make it work as if they submit a web form, but rather another service as you mentioned like Facebook or LinkedIn. I assume this is for some login reason or such. I dont understand fully but a simple one-time code wont work.

Our goal was to setup an API goal in Campaigns and then submit certain persons details that we then update instead of web form but seems like they are designed for two different purposes.