Forum Discussion

BrianCafferelli's avatar
BrianCafferelli
Qrew Captain
5 years ago

The next generation of the Quickbase API

The next generation of the Quickbase API

When we first released our library of Quickbase APIs, it was a historic moment. We were far in front of the rest of the market in making it easy for people to get software to talk to other systems. However, a lot has changed since then in terms of customer expectations and common API patterns. That’s why we’re hard at work building a new set of APIs from the ground up.

You’ll soon be able to try out these new APIs for yourselves, so we wanted to give you a sneak preview of what to expect.

 

APIs, what are they good for?

At the highest level, APIs (short for Application Programming Interfaces) allow people to integrate software systems to get them to work together. Since your business has many different needs, you have a technology stack which includes many different systems. If you’re not careful, this can lead to isolated silos of data that make it hard to see the big picture of what’s going on with your business. Using APIs is an extremely powerful and versatile way to integrate your various systems, since APIs can be used to connect virtually any piece of software on the web.

In Quickbase, APIs are so popular that we get more traffic from our API than we do from users logging into the product on the web.

 

Benefits of the new Quickbase API

  • Simple and modern formatting: Developers can look forward to having a modern, RESTful, JSON-based library of APIs for Quickbase. These APIs will more closely resemble common API patterns and best practices you see with other platforms, helping you to more quickly and intuitively build.
  • Easily test your API calls: Our new API Portal not only documents each API call you can use and how to format them, but it also allows you to quickly test your calls. We’ll also offer more consolidated, intuitive guidance around the terminology you need to build those API calls as well as Javascript and Python code samples.

  • New functionality: We’ve added new functions with our new set of APIs, such as pulling summary reports, getting field usage details, and returning more detail when retrieving an app’s schema.
  • Consolidated set of APIs: We’ve streamlined the collection of about 60 API calls we have today into around 10 calls, focused on the fundamental building blocks of Quickbase: apps, tables, and records. Rather than remember when you need to use API_AddRecord, API_EditRecord, or API_ImportFromCSV, with our new APIs, adding a record is as simple as making a POST request to our records endpoint.

 

We know how crucial integrations are for your business, which is why we’re completely re-imagining the API experience. We want to be bold in defining what the next decade or more of extensibility will look like, and we can’t wait for you to try it out. We’ll be opening an early access in March 2020. If you’re interested in participating, please fill out our registration form and check the “Extending Quickbase” box.

 

Additional resources

8 Replies

Sort By
  • NickWade's avatar
    NickWade
    Qrew Cadet
    5 years ago
    Will it be possible to create client-side apps that utilize the QuickBase API?

    ie: will the CORS restriction be lifted from this new API?
  • hhersch's avatar
    hhersch
    Qrew Captain
    5 years ago
    Hi @Nick Wade can you add some clarity to your question? CORS is a very critical web safety restriction we won't be downgrading. That being said, much of our API traffic comes from client-side/JavaScript pages in the existing API, and our new APIs support that as well. If you can add some information around the patterns you are trying to solve for, we can help better.
  • NickWade's avatar
    NickWade
    Qrew Cadet
    5 years ago
    @Harrison Hersch​ Are those client side apps hosted externally, or pages that are hosted as "QuickBase Pages"?

    Myself and colleagues at my organization have not been able to leverage the QuickBase API directly from a client-side application.

    Are there any examples that you could provide?  

    Below is a sample of what I would expect to work from a client-side app, but the result is this: 

    "Access to fetch at 'https://MY_QB_DOMAIN.quickbase.com/db/MY_APP_DB_ID' from origin 'chrome-search://local-ntp' has been blocked by CORS policy: Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource. If an opaque response serves your needs, set the request's mode to 'no-cors' to fetch the resource with CORS disabled."

    var myHeaders = new Headers();
myHeaders.append("Content-Type", "application/xml");
myHeaders.append("QUICKBASE-ACTION", "API_AddRecord");

var raw = "<qdbapi>\n    <udata>MY_APPLICATION</udata>\n    <apptoken>MY_APP_TOKEN_GOES_HERE</apptoken>\n    <field fid=\"6\">nick</field>\n    <field fid=\"7\">1234 MARKET ST</field>\n</qdbapi>";

var requestOptions = {
  method: 'POST',
  headers: myHeaders,
  body: raw,
  redirect: 'follow'
};

fetch("https://MY_QB_DOMAIN.quickbase.com/db/MY_APP_DB_ID", requestOptions)
  .then(response => response.text())
  .then(result => console.log(result))
  .catch(error => console.log('error', error));​
  • hhersch's avatar
    hhersch
    Qrew Captain
    5 years ago

    @Nick Wade They are Quick Base pages or hosted in a CDN for example and pulled into a browser.​ I'll add some color. When we talk about CORS, there are two categories:

    1. A JavaScript page in realm1.quickbase.com calling realm2.quickbase.com. We don't allow this today and won't in the future.
    2. A page "served" completely outside of Quick Base (like www.mydomain.com) into someone's browser.
    For #2, we will allow CORS from that other domain to the new api endpoint. However, it is important to note that the new API will not allow you to piggyback on the user's current QB session. Since you also should never hardcode a usertoken in JavaScript, the data would either need to be available EOTI or using an intermediary solution hosted on a server.
    ​
  • NickWade's avatar
    NickWade
    Qrew Cadet
    5 years ago
    @Harrison Hersch this would be for an EOTI permissioned app. What I am trying to accomplish is category #2 above. Not cross-domain communication ​​​​within QuickBase.

    That's what prompted my question in the first place because in my experience I would expect an API to be "open" (not restricted by CORS) but require token based authentication for private resources.

    If a QuickBase app has an EOTI user with permission to access a table, then that table isn't considered a "private resource" and the user token is not required.

    It is up to the dev to permission the EOTI user with the appropriate access. The source of the request (client-side or server side) shouldn't matter.

    If a web app is hosted, for example, on AWS S3 should this theoretically work with the new API? But not currently with the existing API?
  • hhersch's avatar
    hhersch
    Qrew Captain
    5 years ago

    Hi @Nick Wade. We really appreciate the details. This is a really deep question and has security implications. Rather than answer off the cuff, it feels like something we need to do a better job at communicating more broadly. I'll work with the team on our side to get a help article drafted and we will post it.

    In the meantime, feel free to reach out privately if you are blocked and we will work together to get you up and running securely.​

  • NickWade's avatar
    NickWade
    Qrew Cadet
    5 years ago
    @Harrison Hersch Thanks Harrison, I will do that! I look forward to seeing an article posted regarding how this should be handled. Thanks for your prompt responses too!​​​
  • RyanAnderson2's avatar
    RyanAnderson2
    Qrew Cadet
    4 years ago
    I've been added to the beta program some days ago and filled out the survey. Is there another email I should have received on details about the Restful APIs and what configurations and addresses I should use to beta test with?  Thanks!