Developer Lab Capstone

Quickbase REST API Developer Review

You began by asking Quickbase for records. By the end of the lab, your JavaScript could inspect Quickbase's schema, discover identifiers, create new schema, construct relationships, capture returned metadata, and verify what Quickbase actually created.

Table of Contents Review Lesson 10

The Big Picture

What the Laboratory Actually Taught

Individual lessons deliberately focused on one concept at a time. The capstone removes those boundaries and shows how the pieces form one coherent Quickbase development model.

Data

READ records

ADD records

EDIT records

DELETE records

Querying

Search criteria

Query operators

Sorting

Pagination

Metadata

App DBID

Table DBID

Field ID

Table / Field / Relationship schema

Schema Construction

Create tables

Create fields

Create relationships

Capture and verify returned identifiers

Evolution

From One Record Query to Application Construction

The project gradually moved from working with data inside an existing Quickbase application to programmatically understanding and modifying the application's structure itself.

Lessons 1A–1B

Read records

Compare the legacy XML API with the modern REST JSON API.

Lesson 2

Control returned data in JavaScript

Sort the records after Quickbase returns them.

Lesson 3

Control what Quickbase returns

Move searching into the REST query instead of filtering everything in the browser.

Lesson 4

Understand query operators

Use EX, XEX, GT, GTE, LT, LTE and learn how Quickbase interprets query criteria.

Lessons 5–7

Complete CRUD

Create, read, update, and delete Quickbase records through the REST API.

Lesson 8

Control result-set slices

Use top, skip, and response metadata to understand server-side pagination.

Lesson 9

Discover schema

Find the current app, its tables, table metadata, fields, Field IDs, and child-side relationships.

Lesson 10

Construct schema

Create tables, fields, and relationships dynamically and verify what Quickbase builds automatically.

REST Map

Endpoints Used Throughout the Developer Lab

These are the Quickbase REST endpoints that became the working vocabulary of the project.

Purpose	Method	Quickbase Endpoint
Read / query records	POST	`/v1/records/query`
Add records	POST	`/v1/records`
Edit records	POST	`/v1/records`
Delete records	DELETE	`/v1/records`
List app tables	GET	`/v1/tables?appId={APP_DBID}`
Get one table	GET	`/v1/tables/{TABLE_DBID}?appId={APP_DBID}`
Create table	POST	`/v1/tables?appId={APP_DBID}`
Get fields	GET	`/v1/fields?tableId={TABLE_DBID}`
Create field	POST	`/v1/fields?tableId={TABLE_DBID}`
Get relationships	GET	`/v1/tables/{CHILD_TABLE_DBID}/relationships`
Create relationship	POST	`/v1/tables/{CHILD_TABLE_DBID}/relationship`

Recurring Pattern

Most Requests Share the Same Architecture

The payload changes. The endpoint changes. The HTTP method may change. But the overall REST conversation remains recognizable.

General request pattern

const response = await fetch(endpoint, {
  method: "POST",

  headers: {
    "QB-Realm-Hostname": REALM,
    Authorization: `QB-TEMP-TOKEN ${temporaryToken}`,
    "Content-Type": "application/json"
  },

  body: JSON.stringify(payload)
});

const data = await response.json();

if (!response.ok) {
  throw new Error(
    `HTTP ${response.status}: ${JSON.stringify(data)}`
  );
}

Method

Describes the operation: GET, POST, DELETE, and so forth.

Endpoint

Identifies the Quickbase API resource being accessed.

Headers

Carry realm information, authorization, and representation details such as JSON content type.

Payload

Supplies the record values, query criteria, field definition, or relationship definition needed by that operation.

Identifier Context

Know Which Kind of Quickbase Object You Are Addressing

Quickbase development quickly becomes easier once identifiers are treated as part of an object hierarchy instead of as arbitrary strings and numbers.

Application
    ↓
App DBID

Table
    ↓
Table DBID

Field
    ↓
Field ID / FID

Record
    ↓
Record ID#

Remember This

A Field ID is not application-wide

FID 6 can simultaneously represent Department Name in Departments, Name in People, and Task Name in Tasks. The Table DBID supplies the context that makes the Field ID meaningful.

Table	Field	FID
Departments	Department Name	6
People	Name	6
Tasks	Task Name	6

Authorization

The Code Page Operates Inside Quickbase Security

The training Code Pages used the signed-in Quickbase session to obtain temporary REST authorization. An Application Token could also be included when the application required one.

Temporary authorization

const response = await fetch(
  `https://api.quickbase.com/v1/auth/temporary/${dbid}`,
  {
    method: "GET",
    credentials: "include",

    headers: {
      "QB-Realm-Hostname": REALM
    }
  }
);

The lab also uncovered an important scope distinction: some operations are table-oriented while others require application context. The DBID supplied when requesting temporary authorization therefore matters.

Table-scoped examples

Get Fields

Get Relationships

Record operations against a table

App-scoped examples

List Tables

Get Table metadata with app context

Create Table

One of the Most Important Patterns

Quickbase Responses Feed Later Requests

By Lesson 10, requests were no longer isolated events. Quickbase returned identifiers that JavaScript retained and then supplied to subsequent operations.

REQUEST
   ↓
QUICKBASE
   ↓
RESPONSE
   ↓
CAPTURE IDENTIFIER
   ↓
NEXT REQUEST

Actual Lesson 10 Dependency Chain

Create Departments
↓
Quickbase returns Table DBID
↓
Create Department Name + Location
↓
Quickbase returns Field IDs
↓
Create Departments → People
↓
Quickbase returns relationship metadata

Remember This

Success is often not the most useful part of the response

The important result may be the new Record ID, Field ID, Table DBID, Relationship ID, metadata count, or another value needed by the next operation.

CRUD Review

One Records Endpoint, Several Different Outcomes

CREATE

POST /v1/records

{
  6: { value: "Walter" },
  7: { value: 44 },
  8: { value: "Orange" }
}

No existing Record ID# is supplied. Quickbase creates a new record and reports it through metadata such as createdRecordIds.

UPDATE

POST /v1/records

{
  3: { value: 14 },
  6: { value: "Walter" },
  7: { value: 45 },
  8: { value: "Orange" }
}

The key field identifies the existing record. Quickbase reports the update through metadata such as updatedRecordIds.

DELETE

DELETE /v1/records

{
  from: TABLE_DBID,
  where: "{3.EX.'14'}"
}

Quickbase evaluates the deletion criteria and reports how many records were removed through numberDeleted.

Querying Review

Ask Quickbase for the Data You Actually Need

One of the major shifts in the lab was moving work away from unnecessary client-side array manipulation and into the Quickbase query itself.

Server-side query

const query = {
  from: TABLE_DBID,

  select: [
    FIELD_IDS.recordId,
    FIELD_IDS.name,
    FIELD_IDS.age,
    FIELD_IDS.favoriteColor
  ],

  where: "{8.EX.'Blue'}",

  sortBy: [
    {
      fieldId: FIELD_IDS.name,
      order: "ASC"
    }
  ],

  options: {
    top: 2,
    skip: 0
  }
};

select

Which fields should Quickbase return?

where

Which records satisfy the query criteria?

sortBy

In what deterministic order should results be returned?

options

How many records should be returned, and how many skipped?

Pagination

The Browser Changes the Instructions; Quickbase Slices the Result

options: {
  top: 2,
  skip: 0
}

// first two records

options: {
  top: 2,
  skip: 2
}

// next two records

options: {
  top: 2,
  skip: 4
}

// next two records

JavaScript did not download every record and then slice the array. Each request told Quickbase which portion of the ordered result set to return.

Metadata	Meaning
totalRecords	Total records in the complete query result set.
numRecords	Number of records returned in this response.
top	Maximum number of records requested.
skip	Number of ordered records Quickbase passes over first.

Schema Discovery

Lesson 9 Changed the Scale of the Project

Until Lesson 9, the application structure was mostly something we already knew. The Schema Explorer showed that Quickbase can describe its own application structure through REST metadata.

Code Page URL
     ↓
Discover APP_DBID
     ↓
GET /v1/tables?appId=APP_DBID
     ↓
Populate table selector
     ↓
User selects a table
     ↓
Get Table
Get Fields
Get Relationships

Get Table

Discover table metadata such as DBID, alias, key field, default sorting, next Field ID, next Record ID, storage, and timestamps.

Get Fields

Discover labels, field types, Field IDs, properties, primary-key and foreign-key behavior, formulas, choices, and other field metadata.

Get Relationships

Discover parent/child relationships, reference fields, lookup fields, summaries, and relationship metadata.

State

Quickbase Became the Source of Truth

Lesson 10 introduced a more sophisticated application-development principle: browser memory is temporary, but the Quickbase schema is authoritative.

PAGE LOAD
    ↓
Discover App DBID
    ↓
GET tables
    ↓
Find People / Departments / Tasks
    ↓
GET fields
    ↓
GET relationships
    ↓
Reconstruct lessonState
    ↓
Determine completed work
    ↓
Enable the next valid action

Remember This

Do not trust transient memory when the authoritative system can be queried

Closing or refreshing the browser resets JavaScript variables, but it does not erase the Quickbase schema. The lesson can ask Quickbase what actually exists and rebuild its client-side state.

Responsibility Boundary

What JavaScript Controls vs. What Quickbase Controls

JavaScript Controls

HTTP method

Endpoint

Request headers

Request body / payload

Query criteria

Which identifiers are supplied

Which response values are retained

What is rendered into the Code Page

Quickbase Controls

Assigned Table DBIDs

Assigned Field IDs

Assigned Record IDs

System fields

Relationship implementation

Reference fields

Lookup fields

Returned metadata

Validation and errors

Higher-Level Operations

Quickbase Often Creates More Than We Explicitly Requested

Create a Table

We Request

Departments

Quickbase Also Creates

Date Created
Date Modified
Record ID#
Record Owner
Last Modified By

Create a Relationship

We Request

Departments → People

Quickbase Also Creates

Related Department
Department Name lookup
Department - Location lookup

Remember This

REST operations can represent higher-level application operations

A Quickbase REST operation is not always a simple one-request, one-object database mutation. Some requests tell Quickbase to perform an application-level operation that requires additional supporting schema.

Relationship Review

Read Relationship Metadata From the Child Side

Departments
    ↓
People

People contains:
  Related Department
  ↑
  reference / foreign-key field

Querying the People relationship endpoint exposes the Departments → People relationship because the reference field lives on People, the child.

Querying Departments may legitimately return:

{
  "relationships": []
}

That does not mean Departments is unrelated. It reflects the child-oriented design of the relationship endpoint.

Vocabulary

Quickbase REST API Terms Worth Remembering

Realm: The Quickbase realm hostname identifying the Quickbase environment where the application lives.
App DBID: The unique identifier of a Quickbase application.
Table DBID: The unique identifier of one table within an application.
Field ID / FID: The numeric identifier of a field within one specific table.
Record ID#: The normal Quickbase record identifier and default table key field.
Application Token: An application-level token that may be required by the application's security configuration.
Temporary Authorization: Short-lived REST authorization obtained using the signed-in Quickbase session.
REST Endpoint: The API URL representing the Quickbase resource or operation being accessed.
HTTP Method: GET, POST, DELETE, or another HTTP verb defining the requested operation.
Request Header: Request metadata such as realm, authorization, and content type.
Payload: JSON sent in the request body to define data, criteria, fields, tables, or relationships.
Response: The HTTP and JSON result returned by Quickbase after processing the request.
Metadata: Additional information Quickbase returns about an operation or result set.
Query Criteria: Quickbase query syntax describing which records should match.
Query Operator: Operators such as EX, XEX, GT, GTE, LT, and LTE that determine how values are compared.
top: The maximum number of records requested from a query.
skip: The number of ordered records Quickbase passes over before returning results.
Parent Table: The one-side table in a Quickbase relationship.
Child Table: The table containing the reference/foreign-key field.
Reference Field: The child-side field storing the relationship reference to the parent record.
Lookup Field: A child-side field whose value is derived from a field on the related parent record.
Relationship ID: In the relationship behavior observed during the lab, Quickbase identifies the relationship through the child-side reference field.
Schema: The structural definition of the application: tables, fields, relationships, and their metadata.

Final Challenge

Read the Code and Predict What Quickbase Will Do

These questions intentionally test Quickbase understanding rather than JavaScript syntax.

Challenge 1 — Create a Field

const endpoint =
  `https://api.quickbase.com/v1/fields?tableId=${tableDbid}`;

const payload = {
  label: "Location",
  fieldType: "text"
};

1. What HTTP method should be used?

2. What does tableDbid identify?

3. Who assigns the resulting Field ID?

4. Where should JavaScript obtain that FID?

Show Answer

Use POST.

tableDbid identifies the target Quickbase table.

Quickbase assigns the Field ID.

JavaScript should read the ID from the successful Quickbase response, such as data.id.

Challenge 2 — Create a Relationship

{
  parentTableId: departmentsDbid,

  foreignKeyField: {
    label: "Related Department"
  },

  lookupFieldIds: [6, 7]
}

1. Which table DBID belongs in the endpoint?

2. Which table is the parent?

3. Where will Related Department be created?

4. Who creates the lookup fields?

5. Why should we not separately POST those relationship lookup fields?

Show Answer

The child table DBID belongs in the endpoint.

Departments is the parent.

Related Department is created on the child as the reference/foreign-key field.

Quickbase creates the requested lookup fields as part of the relationship operation.

They should not be separately created because the relationship operation is the higher-level schema operation responsible for constructing those supporting fields.

Challenge 3 — Explain This Query

{
  from: TABLE_DBID,

  where: "{8.EX.'Blue'}",

  sortBy: [
    {
      fieldId: 6,
      order: "ASC"
    }
  ],

  options: {
    top: 2,
    skip: 2
  }
}

Show Answer

Quickbase queries the specified table, selects records whose Field ID 8 exactly equals Blue, orders the result by Field ID 6 ascending, skips the first two ordered matches, and returns at most the next two.

Debugging

Several Bugs Taught Useful Lessons Too

One stray test variable

An abandoned console.log(testUpdatePayload) stopped the script before DOMContentLoaded, making the table appear broken even though the Quickbase logic was correct.

One stray backtick

A single accidental backtick caused a JavaScript syntax error, preventing every button's click handler from being registered.

Wrong authorization scope

App-level and table-level schema operations demonstrated that the DBID used for temporary authorization matters.

Placeholder DBID

Sending YOUR_TABLE_DBID literally produced a real Quickbase error and reinforced the difference between sample configuration and runtime identifiers.

Remember This

A failed page does not automatically mean a failed API

JavaScript parsing errors, undefined variables, wrong identifiers, invalid authorization, malformed endpoints, and Quickbase API errors produce very different failure modes. Reading the console and the actual Quickbase response was part of the development process.

Final Architecture

The Complete Mental Model

                 QUICKBASE APPLICATION
                         │
          ┌──────────────┴──────────────┐
          │                             │
        DATA                          SCHEMA
          │                             │
    ┌─────┼─────┐              ┌────────┼────────────┐
    │     │     │              │        │            │
   READ  WRITE QUERY          TABLES   FIELDS   RELATIONSHIPS
    │     │     │              │        │            │
    └─────┴─────┴──────────────┴────────┴────────────┘
                         │
                      REST API
                         │
                    JavaScript
                         │
                     CODE PAGE

The Code Page is only the client.

Quickbase remains the application, the data store, the security boundary, the schema authority, and the API server. JavaScript communicates with that system through explicitly defined REST operations.

Keep These

Eight Ideas Worth Carrying Beyond This Lab

Ask Quickbase for only the data you actually need whenever the API can perform the filtering, sorting, or pagination.

Treat App DBIDs, Table DBIDs, Field IDs, and Record IDs as different kinds of identifiers with different scopes.

Capture identifiers from Quickbase responses instead of predicting or hard-coding them.

Remember that a Field ID only has meaning in the context of its table.

Use response metadata as part of application logic, not merely as debugging information.

Recognize that Quickbase can create supporting schema automatically during table and relationship operations.

Read Quickbase relationship metadata from the child-side perspective where the reference field resides.

When client state can be reconstructed from Quickbase, treat Quickbase as authoritative rather than relying solely on transient JavaScript memory.

Developer Lab Complete

You Reached the End of the Quickbase Code Pages Developer Lab

The laboratory began with one People table and a request to read a handful of records. It ends with a Code Page capable of discovering an application's schema, understanding its identifiers, creating new tables and fields, constructing relationships, observing Quickbase-created supporting schema, and verifying the final application state through the REST API.

The purpose was never to memorize JavaScript. The purpose was to understand how a Code Page communicates with Quickbase and how the Quickbase REST API exposes both the data layer and the application schema behind it.

Review All Lessons Return Home View Project on GitHub