Extending Quickbase

This topic provides information about supported and encouraged approaches, design patterns, and security considerations while extending Quickbase.


Quickbase provides a powerful platform for no-code and low-code development, providing you with real-time insights into work processes that can be customized, updated, optimized, and automated in many ways.

Quickbase solutions often provide more value when part of an ecosystem, extending the customization and insights to other systems. When solutions need additional customization or integration, Quickbase offers a rich set of APIs to enhance the platform. Your organization may extend the platform or work with our certified Quickbase Solution Providers (partners).

Important: All uses of Quickbase must comply with any applicable agreements and individual feature restrictions, such as Everyone on the Internet (EOTI). Building solutions that intentionally circumvent Quickbase licensing is strictly prohibited. Quickbase does not control the third-party systems you may integrate with using our APIs and has no control over or responsibility for your data once the data leaves the Quickbase service. We recommend you undertake due diligence on any licensing, security or other restrictions these third parties may have.

General scalability

Quickbase utilizes edge-layer protection with Cloudflare to ensure security and stability of the platform. Quickbase may return an HTTP error 429 in the case where an integrator is making too many requests in a period. Per the RFC spec, integrators should respect the 429 response code and the response header "Retry-After" that indicates how long the originator should wait before trying again.

Internet communication is not perfect and transient faults should be expected. No platform can guarantee 100% communicative round-trip responses, as messages can break down at many different layers, some outside the control of the builder or platform. Builders should instrument their solutions with rich logging, and use API retries with exponential backoff in the case of unpredictable failures.

Server-side integrations

Server-side refers to any solution that is hosted outside of the Quickbase environment and does not run inside of the browser as a client-side solution. Generally, these solutions live and are initiated solely outside of Quickbase. Hosted may refer to servers or serverless environments owned, operated and/or maintained by your organization, services procured from a Quickbase partner or service provider, point solutions that have integrated with Quickbase, or an Integration-Platform-as-a-Service (iPaaS).

Examples of hosted environments include:

  • Colocated servers

  • On-premises servers

  • A virtual machine (VM) running a solution hosted in a cloud Infrastructure-as-a-Service (IaaS) such as Google Cloud Platform, Microsoft Azure, or Amazon Web Services (AWS)

  • Serverless utilities, such as Azure Functions, that are capable of initiating HTTP calls

Most commonly, solutions running on a server are an integration, connecting two or more systems to transfer information back and forth. For these solutions, service account credentials (for example, quickbase_api@example.com) with access to the necessary application must be securely stored on the server or in an accessible key store.

Server-side integrations have several advantages, and some potential disadvantages. A builder’s approach and strategy to the application architecture may be informed by the advantages and disadvantages of server-side integrations, internal guidelines and other outside factors.

The advantages of server-side integration include:

  • Durability: Solutions running on a server can scale better, with more capability to control error handling and retries. They are less prone to crashing or interrupts due to factors such as computer instability or Internet issues, which can occur when the solution runs in a browser.

  • Performance: Client-side enhancements are limited to the performance of the user’s browser and computer they are running in. When running on a server, more computing resources are generally available.

  • Security: Server-side solutions are far more secure when dealing with elements such as authentication, secrets, and tokens. Storing a username and password in a place that will be referenced by a browser is insecure and can easily be compromised.

Potential disadvantages of a server-side solution include:

  • Cost: In general, server-side solutions are more time consuming and expensive to set up.
  • Maintenance: Server-side solutions require an environment to run on, which may include additional requirements such patches and access control.
  • Speed: Depending on the workflow, additional network hops may introduce latency.


This table includes examples of extensions involving Quickbase:




Custom data integration

Your organization

ACME Corp wishes to integrate Quickbase with a legacy ERP system. An engineer at ACME Corp writes .NET/C# code that is hosted locally in the same environment as their ERP system. This code is owned and maintained by ACME Corp and makes API calls to Quickbase to send/receive data before/after communicating with the legacy ERP system and doing the necessary data transformations.

Partner Dropbox integration


ACME Corp wishes to add value to their workflow by integrating Quickbase and Dropbox. A Quickbase partner offers a productized add-on that can be purchased and configured for this add-on. The integration code is hosted, run and maintained by the partner.

Zapier QuickBooks integration


ACME Corp creates invoices in Quickbase and would like to have them sent to QuickBooks Online. Zapier has a connector to both Quickbase and QuickBooks and configure the necessary Zap. The integration code is hosted, run, and maintained by Zapier.

Formstack Documents integration

Formstack Documents

Formstack Documents provides a connector to Quickbase to deliver merged documents to or retrieve information from Quickbase in order to populate a document. ACME Corp has a Formstack Documents account and wants to generate sales documents with Formstack Documents from their Quickbase Opportunities table. The integration code is hosted, run, and maintained by Formstack Documents.

Security and scale considerations

When using a service solution such as an iPaaS or SaaS platform, you should review the security practices of those products to ensure they meet the needed levels of security and compliance for your organization. Even with stringent security standards in place, you must make use of good practices, such as tokenizing, securing, and rotating credentials, and not hard-coding them.

When creating custom solutions, builders should consider authentication and encryption practices that meet industry standards and additional compliance and security needs based on their respective regulatory or company policies. Some of these practices include, but are not limited to:

  • Only connecting to and using TLS endpoints that use modern protocols.
  • Encrypting sensitive data in storage and in transit.
  • Restricting access to code and data based on the least-privilege principle.
  • Where possible, not storing credentials. If storage is required, use modern encryption.
  • Passing sensitive, private, or regulated information into the POST body instead of URL string parameters.


A portal is an example extension where a user interface reads and writes data to Quickbase. This may be used in cases where the needed workflow is specialized, streamlined, and custom, commonly embedded in a company’s website

For appropriate security, this scenario should only ever be performed using server-side techniques. Authentication is needed between both your organization’s server and Quickbase, and between the end user’s browser and the web site hosted on the server.

Your organization is responsible for the security of all server-side integrations, including portals, and how the data is read from and written to Quickbase.

Here are examples of portals involving Quickbase:



Doctor’s office with patient scheduling

Pete’s Podiatry uses Quickbase as their patient management system. They manage patients, scheduling, billing, and other operational functions inside of their Quickbase apps. They would like customers to be able to schedule appointments on their web site. Patients enter their last name, date of birth, and last 4 digits of their Social Security number (SSN) to view a list of available appointment slots, add a new appointment, or adjust one they previously scheduled.

Satellite repair appointment confirmations

ACME Corp performs repairs on residential satellite dishes. When a homeowner calls technical support, that case is entered into Quickbase by the representative. If a service request is needed, the phone rep converts the help case to a service request. An email notification is sent to the customer including a link to a web site where the customer can change or cancel the appointment. The link includes a GUID to reference the appointment record in Quickbase. No personal information is available to read or write on this web site.

In portal use cases like these, the external users are not authenticated with, interacting with, or aware of Quickbase. For all portal implementations and uses of Quickbase:

  • A separate, licensed service account is used for each portal implementation. This account must not be shared with any other server-side utilities, custom integrations or iPaaS tools. For example, if a customer has implemented 3 portals, they must have 3 unique service accounts.
  • The portal meets all security standards provided by Quickbase and by other industry/organization regulations and guidelines.
  • Information sharing from Quickbase to non-authenticated portal users is limited, specific, and non-sensitive. Personally-identifiable information (PII), health information, or financial information should not be presented to the non-authenticated user.
  • An authenticated user must be a discrete individual and non-generic user.

Use cases that fall outside these definitions should be discussed with the Quickbase account management team. Note that all implementations of a portal must respect and adhere to the individual contract, account entitlements, and restrictions.

Client-side enhancements

Solutions written to run inside a browser are generally faster to create, maintain, and deploy, though they generally cannot be as complex.

For low-traffic uses, code can be stored in Quickbase code pages. Low traffic is defined as needing 4 requests or less per second for all the combined resources in a given application. For higher traffic needs, you should store this code on a content delivery network (CDN) or implement browser caching to minimize page queries.

Because of the nature of client-side enhancements, all code is stored on a server, but run locally inside of the user’s browser executing the action, script, or interface. Quickbase only allows JavaScript to be inserted into code pages. Supported methodologies for referencing (or calling) these code pages are:

  • Creating a formula-URL or formula-rich text field
  • In a button on an app home page
  • Using an embedded web widget/iframe on an app home page

Note: You can use a formula-URL field to embed a secure, external website as an iframe on a form. You can use this feature to embed YouTube videos or other file services (Box, Drive, etc.) as a file preview. For security purposes, you can only serve code pages served from .quickbase. All other .quickbase.com URLs do not function when embedded on a Quickbase form.The limits and restrictions of iframes are due to third party limitations, not because of Quickbase.


Here are examples of client-side enhancements involving Quickbase:



Time card approval

ACME Corp has employees submit weekly time cards. Upon submission, a manager needs to review the time cards and have a small custom interface to display analytics on the employee. Pressing the button writes multiple records back to Quickbase.

The builder can create a formula-url button with a formula similar to:

URLRoot() & "db/" & AppID() & "?a=dbpage&pageid=99&rid=" & [Record ID#]

Page 99 is an example reference to an HTML code page with the custom styling needed and includes references to the JavaScript logic. The JavaScript reads the "rid" parameter from the URL to perform the associated queries to Quickbase.

Custom calendar

ACME Corp is looking for a custom calendar view beyond the native capabilities of Quickbase reporting. They intend to have highly visual and custom branding with a tailored workflow specific to this use case. Using an app home page with a button bar or web widget, this custom code page can easily be displayed.

ZIP code radius search

ACME Corp schedules site repairs and manages logistics with a Quickbase app. They often need to cross reference addresses of known subcontractors with the addresses of customers looking for a repair. On the Opportunity record inside of Quickbase, they push a button to launch a custom interface and perform this analysis.

The builder can create a formula-url button with a formula similar to:

URLRoot() & "db/" & AppID() & "?a=dbpage&pageid=88&rid=" & [Record ID#]

Page 88 is an example reference to an HTML code page with the custom styling needed and includes references to the JavaScript logic. The JavaScript reads in the "rid" parameter from the URL to perform the associated queries to Quickbase to find the customer’s ZIP code. This information can then be used to query a third-party service with the source ZIP code and other necessary parameters such as the tolerance of radius in miles. The ZIP codes returned from the other service can then be used to query Quickbase for matching subcontractors.

Warning: Quickbase cares deeply about the security and reliability of the platform. To that end, the following techniques are unsupported and may put applications and organizations at risk for security breaches and reduce the manageability of applications. Quickbase teams cannot support these techniques.

Unsupported techniques

  1. Implementations that leverage unpatched bugs or vulnerabilities to inject JavaScript into places not specifically defined as allowed, or to manipulate Document Object Models (DOMs).
  2. Sniffing network traffic to rely on Quickbase-internal API calls.
    • Publicly-supported and maintained API calls begin with the prefix API_. Any other prefix denotes an API call that Quickbase does not provide support for, may be deprecated, or removed without customer notice.
  3. Observing and depending on Quickbase client functions such as DoSave() for custom implementations, except where noted or documented by Quickbase.
    • These functions may be deprecated or changed without customer notice.
  4. Relying on, consuming, inspecting, or leveraging libraries hosted by Quickbase as part of the platform. These may be removed or altered at any time.

Quickbase cannot regression test for these methods and application functionality may break without notice or support from Quickbase. Builders are encouraged to report security vulnerabilities in accordance with guidance on how to responsibly report a security issue.

Solutions that combine server-side and client-side technologies

Solving for certain scenarios may require a solution that is initiated client-side (such as a button press) and leads to a server-side dependency. In these scenarios, there are two different authentication models possible.

  1. Stored service account (for example, quickbase_api@example.com) credentials.

    1. You might need this type of solution when you want a user to initiate an action that requires elevated privileges beyond what the authenticated user has access to do, such as delete records, even though the signed-in user does not have privileges to delete.

    2. All record modifications and accountability are tied to the service account, rather than the user that pushed the button.

    3. To meet minimum security standards, access to the solution should be restricted using common security practices. As many of the following approaches as possible (based on business logic and requirements) are recommended:
      1. IP address filtering

      2. Single sign-on (SSO)

      3. Validating Quickbase sessions client-side before providing access to resources

  2. Temporary authentication passed from the client.

    1. No server-side credentials are stored. This reduces an attack vector because no credentials can be compromised from a server.

    2. All permissions, record modifications, and accountability are tied to the user pressing the button.

Example using both options

ACME Corp regularly has insurance billing agents scan approval and denial letters into Quickbase and associate them with patients. In certain cases, depending on the scanner’s configuration, multi-page files are uploaded individually as separate files. Rather than manually downloading and merging these files, their line of business worked with their internal IT team to develop an extension to Quickbase.

Server side

The builder creates a button in a formula-url field on the patient record. This field is configured with a formula like:

"https://acmecorp.example.com/mergepdfs?qbrid=" & [Record ID#]

When pushing this button, code written by ACME Corp’s IT team launches a custom interface hosted in their corporate Azure environment. It has a custom interface that queries Quickbase based on the Record ID# passed in the URL, using the stored credentials on the server. The user then selects the files they want to merge into one. The code in Azure downloads the files from Quickbase and then uses a library that ACME Corp’s IT department has licensed and approved for use. This library merges the files together, returning one PDF which is ultimately written back to Quickbase. This file has a record owner of "ACME API." For security, any temporary files stored locally on the server are deleted automatically.

Client side

The builder creates a button in a formula-url field on the patient record. This field is configured with a formula like:

URLRoot() & "db/" & AppID() & "?a=dbpage&pageid=77& "&rid=" & [Record ID#] 

When pushing this button, a Quickbase code page is launched. It retrieves a temporary authentication token and performs an HTTP POST and redirect to the following:

"https://acmecorp.example.com/mergepdfs?qbrid=" & [Record ID#]

This passes in the temporary authentication ticket. The user experience and core logic are the same as the above. The file ultimately created has a record owner of the user who pressed the button.

Development process

Builders should follow best practices for the development, maintenance, and change management of Quickbase enhancements. Code should be maintained in a suitable source code management tool. Testing should include unit, integration, and regression test cases. Builders should have clear separation of duties and appropriate controls and approval chains for releases or changes.


Unless noted otherwise, Quickbase does not provide support for custom code, external solutions, or custom hosting, however, we will provide technical support, architecture overview, and guiding principles for the API calls that interact with Quickbase. Builders looking for assistance should capture the raw (XML, JSON) request/response from their tool set and the Quickbase API call being used when opening a case with Quickbase Customer Care.

Important: Always be sure to obfuscate or remove authentication and any other sensitive information before providing logs to any external party, including Quickbase Customer Care.

Involving third parties

When third-party SaaS solutions are involved, support should generally be routed to the service that is returning or providing the error or behavior needing investigation. If another service needs clarification or assistance on Quickbase APIs they are integrating with or platform details, Quickbase will gladly assist.

Support examples


Level 1 support or initial system to investigate

Using a webhook to a legacy ERP system. The system is returning an authorization error as discovered in the Quickbase webhook error history.

Developers of the ERP system to explain authentication protocol.

Sending a webhook to a legacy ERP system. Evidence suggests the webhook is not leaving the Quickbase app.

Quickbase to determine if and why the webhook is not being sent from Quickbase. If the webhook is being sent, Quickbase will provide the necessary information for customers to contact the ERP developers to investigate why it is not being received.

Using Formstack Documents to create documents and have them uploaded to Quickbase after creation. The document/record is not showing up in Quickbase when expected.

Formstack Documents to investigate if the API call is being sent to Quickbase and/or if an error is being received. If an error from the Quickbase API is being returned, Quickbase Customer Care can assist.

Using Workato to receive new customers from Salesforce and create them in Quickbase. The data being written to Quickbase appears to be inconsistent with what is in Salesforce.

Workato to determine if the proper configuration is present to transform the data between Salesforce and Quickbase data types. Investigation may lead to Salesforce to find out why certain data is not being returned or Quickbase to format data as expected for the Quickbase API or individual application.

Creating a custom JavaScript interface that is launched when a button is pressed to approve timecards. This page is popping up but not loading.

The developer of the custom code page. If API calls are failing to Quickbase, the developer can troubleshoot and open a Quickbase Customer Care case for API assistance.