Sites
Sites represent client-owned physical locations.
Use siteCode as your stable site identifier. It must be unique for your client
account.
Common operations:
GET /sitesPOST /sitesGET /sites/{id}PATCH /sites/{id}
List responses support page[size] and page[after]. When more records are
available, the response meta.nextCursor value can be sent as the next
page[after] value.
GET /api/v1/sites?page[size]=25
Authorization: Bearer YOUR_ACCESS_TOKEN
Resolve a known client-side identifier with an exact-match list filter:
GET /api/v1/sites?siteCode=SEA-10027
GET /api/v1/sites?uniqueID=KIOSK-12
GET /api/v1/sites?uniqueID2=ASSET-77821
Use only one of these filters per request. The response keeps the normal list
shape and returns either the matching client-owned site or an empty data
array.
The API derives client ownership from your access token. Do not send a tenant ID or Quickbase record ID.
Create sites with a stable client identifier and a unique Idempotency-Key.
Use the same key and request body when retrying after a timeout or transient
failure.
POST /api/v1/sites
Authorization: Bearer YOUR_ACCESS_TOKEN
Idempotency-Key: import-2026-05-14-sites-row-000123
Content-Type: application/json
{
"name": "Demo Store 100",
"siteCode": "DEMO-STORE-100",
"addressLine1": "123 Main St",
"city": "Phoenix",
"stateRegion": "AZ",
"postalCode": "85001",
"country": "US"
}
GET /sites/{id} responses include an ETag header. Send that value in
If-Match when patching a site so the API can reject stale updates.
PATCH /api/v1/sites/site_123
Authorization: Bearer YOUR_ACCESS_TOKEN
If-Match: "1"
Content-Type: application/json
{
"friendlyLocationName": "Front counter"
}
Legacy fields uniqueID, uniqueID2, friendlyLocationName, and
friendlyLocationName2 may still appear on site responses for backward
compatibility. New site-visit asset assignment workflows should use
site-specific Site Assets configured in SSN rather than relying on those
legacy site-level fields.
See the API Reference for the full site request and response schemas.