## TL;DR
The Table API looks up records by sys_id, and 'record not found' means the id doesn't resolve for this caller: it's mistyped, the record was deleted, or ACLs hide it. The UI and the API enforce the same ACLs, so 'works in UI, fails in API' usually means different users. Verify the sys_id, the table, and the caller's access in that order.

## The query

```text
servicenow table api record not found
```

## Use this when

- Table API reads fail with 'record not found'
- A sys_id works in the UI but not through the API
- An integration breaks after an access change


## Not for

- ServiceNow authentication failures
- Encoded query syntax errors
- Business rule or client script errors


## Steps

### 1. Verify the sys_id and table

Confirm the 32-character sys_id is complete and the table name is right (incident vs task vs your custom table). Truncated ids from logs and wrong-table lookups are the boring causes. Query the table directly with the sys_id.

Expected output: the record returned by a direct sys_id query, or confirmed absent.

### 2. Check whether the record still exists

If the direct query also misses, the record was deleted or never existed in this instance. Check audit history and whether you're pointed at prod vs dev: sys_ids don't transfer between instances.

Expected output: the record's existence confirmed in the instance you're calling.

### 3. Test ACLs as the integration user

Impersonate the integration user and try to open the record in the UI. If it's hidden there too, an ACL change is the cause. Table API respects ACLs exactly like the UI does.

Expected output: the impersonation test showing the record visible or hidden.

### 4. Fix the source of the sys_id

If the sys_id came from a webhook, an export, or another system, that source is stale or wrong. Trace one failing id back to where your code got it and fix the handoff.

Expected output: the sys_id source identified and corrected.

## Variant phrasings

### servicenow rest api record not found sys_id

Steps 1 and 3: exact id first, then the ACL test.

### servicenow table api 404

Step 2's instance check; dev-vs-prod mixups are common.

## Why it happens

ServiceNow's ACLs make 'not found' ambiguous by design: the API won't distinguish 'doesn't exist' from 'you can't see it', because confirming existence would leak data. So the error is honest but unhelpful, and the debugging has to consider visibility as a first-class cause, not an afterthought.

## Edge cases

- Display values vs sys_ids: the API wants sys_ids. Display-value lookups need a query, not a direct get.
- Table inheritance (task to incident) can confuse table names. Query the specific table.
- Deactivated users' records may hide from some roles. Check the caller's role set.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_WrkDXYlWXJ4Cf77gU2Mprg