Infusionsoft API Glossary

API Q&A
,
1

This is to help us all stay on the same page while communicating. If you have additional suggestions please add a comment.

Term Definition
API The Application Programming Interfaces enables software to interact with other software through exposed functionality by using XML-RPC or REST while being authenticated through the Legacy Authentication Method or oAuth.
API Key The encryption key generated by Infusionsoft when using the Legacy Authentication Method. How to obtain then encryption key can be found here.
Application Name Able to be found in the url when logged into Infusionsoft CRM after "https://" but before ".infusionsoft.com". The application name is generally two letters followed by three numbers.
Client Id A 24 character string that is used to obtain authorization from a user to access Infusionsoft
Client Secret A 10 character string that is used to obtain authorization from a user to access Infusionsoft. This should not be shared with anyone and support will only ask for the last four characters to verify that is is being passed correctly.
Contact Saved information for people that a company contacts. This type of record includes things like name, phone number and email address
CORS Cross-Origin Resource Sharing allow javascript in websites to do AJAX requests to domains beyond the one initiating the request. This type of request is not allowed by Infusionsoft's API and will result in a "CORS origin denied" error message
Developer application Used to access one or more Infusionsoft applications using oAuth. The developer application name and other information can be found here. This includes the client id, client secret, application name and current status of the developer application.
Encryption Key This is the Legacy manner for obtaining access to the API. It requires a user to log into the application and preform multiple actions to generate a key. They key then needs to be shared with a developer. Please see this article on how to obtain an encryption key. Please see Legacy Authentication Method before attempting to use this method.
Legacy Authentication Method A method of obtaining access to the application by obtaining access from a user. The setup of this method is no longer supported although applications that are on this method can still be used. We highly encourage the use of oAuth as a authentication method as new functionality has been added that is unavailable to the Legacy Authentication Method.
Legacy Key The encryption key generated by Infusionsoft when using the Legacy Authentication Method. How to obtain then encryption key can be found here.
oAuth Open Authentication is a standard for authorization on the internet used by most major companies to authorize access to services. This method allows a developer application to obtain permissions without having a user's password. Infusionsoft suggests using this method for Authentication as it can use both XML as well as REST API calls.
Opt-In This referrs to an email address. An opted in email address is one that is marketable. There are a few email statuses that will allow emails to be sent out, unconfirmed, confirmed, confirmed legacy, unengaged marketable. To read more on email statuses go here.
REST Representational State Transfer uses HTTP to transport requests to Infusionsoft by using GET, PUT, POST, PATCH and DELETE for data manipulation
REST Hook REST Hooks itself is not a specification, it is a collection of patterns that treat webhooks like subscriptions. These subscriptions are manipulated via a REST API just like any other resource. As records are added or updated a count can be done to make a data sync as effecient as possible.
SDK A software development kit is a starting point for a development project that speeds up development by allowing the use of API methods and services in an easily implementable manner.
XML-RPC The use of XML with a remote procedure call to request Infusionsoft to preform a particular action. This allows Infusionsoft and another system to speak in a similar language dispite the programming language that is used or in other words any programming language that allows XML can communicate to Infusionsoft
5 Likes
2

CORS is an acronym of the phrase “Cross-Origin Resource Sharing”.

See Cross-Origin Resource Sharing (CORS) - HTTP | MDN

The definition states “Cross Origin Requests allow websites to …”
Cross-Origin Requests do not allow websites to perform the described requests; such actions are made safely possible by implementations of the CORS specification.

CORS is the “… mechanism (that) gives web servers cross-domain access controls…”; which provides the authorization/authentication structure for Cross-Origin Requests.

3

The request might be safe but the host site allowing CORS is not safe and therefor is not allowed. It is a huge security risk and also is NOT PCI compliant which Infusionsoft servers must be. It’s not pci compliant for a reason. It is not secure and in fact introduces more than one way to breach a sites data.

4

Your answer reveals an aspect of this issue that I’d forgotten in my original post; which is that Infusionsoft clearly implements CORS as part of their REST-ful API. It’s an additional troubling aspect of this glossary entry.

Here’s a screenshot after pressing the TRY button.

image
image956Ă—320 34.8 KB

But, what do I know.

Anyway, CORS is an acronym that isn’t defined in the glossary.

5

@Jeffrey_Chimene, elaborating on some elements of @John_Borelli 's reply…

There are safe ways to handle CORS requests, and our PCI compliance is not why we have CORS disabled for anything other than our developer portal. One of these is domain whitelisting. In order to protect our customers we only whitelist the developer.infusionsoft.com domain. I am not sure if the glossary has been updated since the last comment, but in it’s current state it is clear that we do not support CORS preflight when API calls originate from the browser. I understand that you have dug and revealed we indeed support CORS for the interactive docs, but we do have it whitelisted because we control the developer.infusionsoft.com and can guarantee that the API requests that happen via the browser are legitimate and safe.

We usually recommend that API calls from the browser be sent to your backend in a domain controlled by you (the developer). Then that backend will make the actual API calls. Otherwise you would need to expose your client_id and client_secret in the browser. This is allowed on developer.infusionsoft.com because as a consumer of the docs you provide your own client_id and client_secret. This would be a very bad experience obviously for someone attempting to use an integration who does not have a client_id nor client_secret.

Hope that clears things up. If not, please continue to ask away!

EDIT
@JonSmith did update the glossary before my post :slight_smile:

6

The acronym has been updated. Thank you for catching this and letting us know.

7

In your OAuth implementation, would it be correct (secure) to authorize the application using backend comms., then send the access_token to the frontend for subsequent comms?
I realize the access_token will expire. IOW, I don’t see anything in the TRY result that would be the CLIENT_ID / CLIENT_SECRET pair.
What am I missing?