Lesson 7

Delete Records with the Quickbase REST API

Complete the CRUD cycle by safely selecting an existing People record, identifying it with a Quickbase query condition, deleting it through the REST API, and confirming the result from Quickbase's response.

Lesson Objective

Remove One Existing Record — Deliberately and Safely

Lesson 7 introduces the destructive side of CRUD. Unlike CREATE and UPDATE, DELETE uses a Quickbase query condition to determine which record should be removed. We will verify the target, ask the user for confirmation, send the DELETE request, read Quickbase's acknowledgment, and refresh the table.

The Milestone

One More Operation and the People Page Becomes Full CRUD

Create

Lesson 5

Add a new Quickbase record.

Read

Lesson 1B

Retrieve Quickbase records.

Update

Lesson 6

Change an existing record.

Delete

Lesson 7

Remove an existing record.

The Important Change

DELETE Does Not Use the Same Payload as CREATE and UPDATE

CREATE and UPDATE send record data. DELETE instead tells Quickbase which records qualify for removal.

CREATE / UPDATE

{
  to: TABLE_DBID,
  data: [
    {
      ...
    }
  ]
}

Send record values to Quickbase.

DELETE

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

Tell Quickbase which record matches the deletion condition.

Aha Moment

The Query Language from Lessons 3 and 4 Is Back

We first used Quickbase query conditions to control which records were returned by a READ. In Lesson 7, the same query language determines which record will be deleted.

{ 3 . EX . '14' }
  │    │      │
  │    │      └── Record ID# 14
  │    │
  │    └───────── Exactly equals
  │
  └────────────── Quickbase Field ID 3

Earlier

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

Meaning:
Return records where
Favorite Color = Blue

Lesson 7

where:
"{3.EX.'14'}"

Meaning:
Delete records where
Record ID# = 14

Lesson 7 Roadmap

Six Steps from Selected Record to Confirmed Deletion

Because DELETE is destructive, this lesson deliberately separates targeting, verification, confirmation, execution, acknowledgment, and refresh.

Add a Delete action

Give each People record a Delete button beside Edit.

Build the deletion target

Use Record ID# to create a Quickbase where condition.

Confirm before deleting

Ask the user to explicitly approve the destructive action.

Send the DELETE request

Submit the from/where payload to the Quickbase REST records endpoint.

Read Quickbase's acknowledgment

Inspect numberDeleted to learn what actually happened.

Reload and verify

Read the People table again and confirm the record is gone.

Add a Delete Action to Each Record

The Actions column now contains both Edit and Delete. The Delete button carries only the values necessary for the deletion workflow: the Quickbase Record ID# and a readable name for confirmation.

const deleteButton =
  document.createElement("button");

deleteButton.type = "button";
deleteButton.textContent = "Delete";
deleteButton.className = "delete-button";

deleteButton.addEventListener("click", () => {
  deletePerson(recordId, name);
});

Record ID# is once again the key.

The browser already knows the ID of every rendered People record. That value becomes the foundation of the deletion target.

Build the DELETE Payload

Instead of supplying record values, the DELETE payload identifies the source table and provides a Quickbase query condition.

function buildDeletePersonPayload(recordId) {
  return {
    from: TABLE_DBID,

    where:
      `{${FIELD_IDS.recordId}.EX.'${recordId}'}`,
  };
}

Example

Record ID#: 14

        ↓

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

Destructive Operation

A DELETE Query Deserves More Care Than a READ Query

In Lessons 3 and 4, a bad where condition might return the wrong records. In Lesson 7, the condition determines which records Quickbase removes.

READ with wrong condition
        ↓
Wrong results appear

DELETE with wrong condition
        ↓
Wrong records may be removed

That is why we tested the payload before sending the DELETE request.

Ask for Confirmation

Before contacting Quickbase, the Code Page asks the user to confirm the exact person and Record ID# being deleted.

const confirmed = window.confirm(
  `Delete ${name} from Quickbase?

Record ID: ${recordId}`,
);

if (!confirmed) {
  return;
}

No confirmation means no API request.

Returning here stops the delete workflow before temporary authorization or the destructive REST request occurs.

Send the DELETE Request

CREATE and UPDATE used POST. Lesson 7 changes the HTTP method to DELETE, while still using the Quickbase records endpoint.

const response = await fetch(
  "https://api.quickbase.com/v1/records",
  {
    method: "DELETE",

    headers: {
      "QB-Realm-Hostname": REALM,

      Authorization:
        `QB-TEMP-TOKEN ${temporaryToken}`,

      "Content-Type": "application/json",
    },

    body: JSON.stringify(payload),
  },
);

Operation	Method	Endpoint
CREATE	`POST`	`/v1/records`
UPDATE	`POST`	`/v1/records`
DELETE	`DELETE`	`/v1/records`

Read Quickbase's DELETE Acknowledgment

Just like CREATE and UPDATE, DELETE answers with structured JSON. This time the response is wonderfully direct.

const data = await response.json();

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

Quickbase Response

{
  numberDeleted: 1
}

The query matched one record, and Quickbase deleted one record.

Request / Acknowledgment

Every Write Operation Has Told Us What Happened

CREATE

metadata.createdRecordIds

Quickbase tells us which new Record ID# it created.

UPDATE

metadata.updatedRecordIds

Quickbase tells us which existing Record ID# changed.

DELETE

numberDeleted

Quickbase tells us how many records were removed.

Reload the People Table and Verify the Deletion

After Quickbase confirms the delete operation, the Code Page performs another READ. The removed record disappears because it no longer exists in the Quickbase table.

status.textContent =
  `${name} was deleted from Quickbase.`;

await loadPeople();

Quickbase remains the authoritative source.

We do not merely remove the HTML row ourselves. We read the table again and render the records Quickbase now contains.

Complete DELETE Flow

TARGET → CONFIRM → DELETE → ACKNOWLEDGE → READ → VERIFY

READ People records
      ↓
Render Delete button
      ↓
Click Delete
      ↓
Record ID# selected
      ↓
Build query condition
      ↓
{3.EX.'14'}
      ↓
Ask for confirmation
      ↓
User confirms
      ↓
DELETE /v1/records
      ↓
Quickbase evaluates where
      ↓
Matching record removed
      ↓
numberDeleted: 1
      ↓
Show success message
      ↓
await loadPeople()
      ↓
READ current Quickbase records
      ↓
Deleted record is gone

Major Milestone

The People Code Page Is Now Full CRUD

We did not start by trying to build a CRUD application. We built one capability at a time, proved each piece independently, and gradually arrived here.

CRUD	Lesson	Quickbase Operation
Create	Lesson 5	`POST /v1/records`
Read	Lesson 1B	`POST /v1/records/query`
Update	Lesson 6	`POST /v1/records`
Delete	Lesson 7	`DELETE /v1/records`

How We Got Here

Look at What the Little People Table Taught Us

The People table is deliberately tiny, but the development concepts are not. The same four fields have carried us through nearly the entire foundation of Quickbase Code Page development.

REST Authentication

Acquire temporary authorization from the signed-in Quickbase session.

JSON Requests and Responses

Send structured requests and interpret structured Quickbase responses.

Field IDs

Use stable Quickbase field identifiers when reading and writing records.

QDL Conditions

Build conditions such as {8.EX.'Blue'} and {3.EX.'14'}.

Record Identity

Use Record ID# to recognize, update, and delete specific records.

CRUD Workflows

Combine browser interaction, REST calls, acknowledgment, and verification.

The Bigger Picture

We Built a Two-Way Conversation with Quickbase

READ
Quickbase ───────────────→ JavaScript
          records


CREATE
JavaScript ──────────────→ Quickbase
          new values

Quickbase ───────────────→ JavaScript
          createdRecordIds


UPDATE
JavaScript ──────────────→ Quickbase
          Record ID# + changed values

Quickbase ───────────────→ JavaScript
          updatedRecordIds


DELETE
JavaScript ──────────────→ Quickbase
          where condition

Quickbase ───────────────→ JavaScript
          numberDeleted

That request-and-acknowledgment pattern is one of the most important things this CRUD sequence revealed. The Code Page is not merely firing commands at Quickbase. Each operation is a structured exchange.

CRUD Complete

We Built Something Real

The Code Page can now read the People table, create new People records, select and update existing records, and safely delete records. Every operation is backed by a real Quickbase REST request and a real Quickbase response.

CREATE   ✅
READ     ✅
UPDATE   ✅
DELETE   ✅

FULL CRUD ✅

And we got here without hiding the machinery. We watched the authentication, payloads, query conditions, Record IDs, responses, metadata, failures, confirmations, and refreshes happen one step at a time.

Lesson 7 Complete

The CRUD Foundation Is Finished

You targeted an existing Quickbase record with QDL, protected the destructive action with confirmation, sent a DELETE request, interpreted numberDeleted, refreshed the table, and completed the full CREATE, READ, UPDATE, DELETE sequence.

Next: Lesson 8 — Pagination

The application can now perform CRUD. The next challenge is scale: what happens when the table contains far more records than we want to retrieve and render at once?