Don't forget to check out our JSON RESTful APIs, they can help you utilize and extend Quickbase with ease.
The Quickbase API can be invoked in either of two ways.
As an XML request string POSTed to Quickbase
As a URL sent in a GET request (e.g. sent from a browser, or embedded in a web page or Word document).
Note that there are many samples throughout this guide for both XML and URL requests. The parts of these sample calls that reference specific information, such as authentication ticket, application token, user token, app or table dbid, and customer domain are represented by italicized sample text, as shown below:
An authentication ticket - auth_ticket
An application token - app_token
A user token - user_token
An app or table dbid - target_dbid
A Quickbase domain addressed by the call - target_domain
For most API calls, Quickbase returns a response in XML format. For certain API calls that are embedded in a web page or Word document, Quickbase returns HTML responses.
Understanding the XML Samples
Each sample can be divided into two sections: the POST request method and the actual API call.
POST request method
An example of the POST request method appears below.
The first three lines shown above are standard HTTP headers for the POST request method. The first line specifies that the secure HTTPS protocol should be used and contains the URL for the POST. The URL includes the target_domain, or the domain against which you are invoking the call (for example, quickbase.com). The URL also includes the target_ dbid, which identifies the app or table the call should address.
The last line is a custom Quickbase header containing the API call.
The second part of each sample illustrates the syntax for the API call. The elements between the
<qdbapi> tags are the parameters; these are documented for each API call.
<mode>mode</mode> <!-- optional unless lookup or formula-->
<udata>whatever</udata> <!--optional pass-thru data -->
Order of parameters in API calls (XML or URL)
Quickbase accepts API call parameters in any order, whether the call is made via XML or a URL.
Using key fields
By default, each table has the built-in Record ID# (rid) field, which provides the unique key for that record within the table. You can use another field as the key field if you'd like, as long as the new field type supports the Unique property.
If you use a field other than the Record ID# as the key field, you may be able to replace the &rid parameter in many of the API calls with the &key parameter. The following API calls support this substitution: