In last week’s episode of “Schemas” we discussed how to bring together information from different cloud applications. Today in our exciting mini-series finale we will take a look at how to find the pieces of information that you need.
In order to access information from one application inside another, you must use an Application Programming Interface, or API for short. What is an API? Well, if you think of your cloud applications as cities, then APIs are the roads which connect those cities – the specific pathways into and out of each one. Some roads are toll roads — i.e., some apps charge for access to their APIs — while others are free. In some cases you may not know that you are riding these highways — for example, in the case of QuickBase Sync, all of the programming that connects your cloud apps to QuickBase is managed for you — but the APIs are still there underneath.
That said, it is impossible to completely escape the fact that you are dealing with APIs, because it is the APIs which determine what kind of traffic flows on the highways — in other words, the APIs define what data is available from a given application. The format of that data is — you guessed it — the schema.
Depending on the API, schemas can be intuitive. For example, the Salesforce API has an Account table which contains information on Salesforce customer accounts organized just as they are when you log into Salesforce.com and look at an account on the page. In other cases, the API schema can be a departure from what you know as a user of the application. For example, if you are looking at Intuit QuickBooks Online you might want to find an invoice by its invoice number. But if you look at the schema for the Invoice table, you will not find a column called “Invoice Number” — instead, the QuickBooks API refers to this as “DocNumber.”
OK, maybe that last example wasn’t too confusing. But how about this — one of the more complex things API schemas do is separate information across many different tables. For example, you might be looking at the Case table in Salesforce, but you will not see any customer Account information there. That’s because the customer Account information is stored in the Account table. Makes sense. But when you are dealing with cases you still want to know some of the customer information. As we discussed last week, you will need to join the two data sets together – linking Case with Account based on the AccountId. And in fact, Case isn’t just related to Account — it also has associations to other things like Asset, History, and User.
One option would be to grab a copy of the API reference documentation, but at that point you might as well be programming the integration yourself. Thankfully, QuickBase Sync comes with a number of pre-built data sets (queries) that strip away much of this schema complexity. Under the label “Optimized for QuickBase,” these queries do things like join raw API tables together and rename columns to make them more familiar to users of cloud apps rather than API developers. While they may not be right in all situations, in many cases, these queries can save a lot of confusion and heartache.
Learn more about QuickBase SyncTeam Productivity | Tagged API complexity, Integrations, QuickBase Sync, Schemas, Sync