Extending Quickbase

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

• Overview
• General scalability
• Server-side integrations
  • Examples
  • Security and scale considerations
  • Portals
• Client-side enhancements
  • Examples
• Solutions that combine server-side and client-side technologies
  • Example using both options
• Development process
• Support
  • Involving third parties
  • Support examples

Overview

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" which indicates how long the originator should wait before trying again. If you see this error while making an API request, it means you’ve exceeded the number of requests you can make for a certain period of time. Check the documentation for each usage. 

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.

Examples

This table includes examples of extensions involving Quickbase:

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.

Portals

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:

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.

Examples

Here are examples of client-side enhancements involving Quickbase:

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

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

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 either:
     • XML: Begin with the prefix API_ and are documented in our XML API Guide.
     • JSON: Are documented in our RESTful API Guide
   • Any prefix other than API_* 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.

Supported techniques

Note that Quickbase RESTful APIs are fully supported. Our publicly supported and maintained API calls are either documented in our XML API guide or our RESTful JSON APIs. Supported XML calls are always denoted by API_*, for example: API_DoQuery.

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.

Support

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 Technical Support.

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

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