> ## Documentation Index
> Fetch the complete documentation index at: https://support.configview.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Reftab setup

ConfigView reads your Reftab asset register through Reftab's REST API, using an **API key pair** (a public key and a secret key) that you generate in Reftab. Every request is signed with the secret key; the secret itself is never sent.

You will end up with **2 secrets** in ConfigView (`REFTAB_PUBLIC_KEY`, `REFTAB_SECRET_KEY`) when setup is complete.

> **Scope of this integration today.** ConfigView ingests Reftab's **asset register and who holds what**: assets (with serial numbers), accessories, licences and the applications they belong to, loans (check-outs), borrowers and Reftab users, requests, reservations, maintenance and verifications. ConfigView only reads. It never checks items in or out or edits records.

***

## Step 1: Open the Reftab page in ConfigView

Open ConfigView in a second browser tab and leave it open:

`https://{companyname}.configview.com/admin/integrations/reftab`

Reftab shows the secret key once, when you create the pair, so paste it straight into ConfigView instead of keeping it in a notes file.

***

## Step 2: Create an API key pair in Reftab

1. Sign in to [Reftab](https://www.reftab.com/) as the user whose access ConfigView should have. **Use a shared service account with an Admin role** (for example `integrations@`), not a person's own login. See *Which user owns the key* below
2. Open **Settings** and find the **API** section
3. Create a new API key. Reftab shows a **public key** and a **secret key**
4. Switch to the ConfigView tab and paste each one into its row under **Credentials**, clicking the save icon on each:

| Reftab shows | Paste into ConfigView as |
| - | - |
| **Public key** | `REFTAB_PUBLIC_KEY` |
| **Secret key** | `REFTAB_SECRET_KEY` |

### Which user owns the key

A Reftab API key acts as the user who created it and sees only what that user's **role** can see. If the user can't view licences, or only some locations, ConfigView can't either, and the gaps don't look like errors. They show up as fewer rows. An Admin role sees everything.

Reftab ties the key to that user. If the user is disabled or deleted, collection stops, so a service account that won't leave is the safer owner. You can revoke a key from the same Settings page at any time.

***

## Step 3: Connect and verify

1. Back on `https://{companyname}.configview.com/admin/integrations/reftab`, confirm both credentials show as saved
2. Click **Connect**. ConfigView creates its tables and schedules every collector at your default run time. Stop any you don't want under **Collectors**:

| Script | Notes |
| - | - |
| **Assets** | Every asset with category, location, status, serial number, current borrower and due date. |
| **Accessories** | Accessories and consumables: quantity, available, in use, reorder minimum, vendor. |
| **Asset Categories** | Categories, asset counts and the custom fields defined on each. |
| **Locations** | Every location and sub-location, flattened to one row each with its parent and depth. |
| **Licenses** | Licences, active **and** cancelled: seats bought and used, cost, expiry and cancellation dates. |
| **Applications** | SaaS applications tracked in Reftab, with vendor, owners, status, cost and roles. |
| **Loans** | Every check-out, open and returned, of an asset, licence, accessory or kit. |
| **Borrowers** | Everyone who can be lent equipment: borrowers and Reftab users in one list. |
| **Users** | Reftab user accounts, enabled and disabled, with role. |
| **Requests** | Asset and accessory requests in every state, with approval history. |
| **Reservations** | Reservations: upcoming, fulfilled and cancelled. |
| **Asset Maintenance** | Open and completed maintenance jobs per asset. |
| **Verifications** | Verifications sent to borrowers to confirm they still have an item, and their answers. |

3. Click **Verify now**. The health check signs one request to confirm the key pair, then reads one record from each kind of data above.

If a check fails:

* **API key signature fails with 401.** The two keys aren't a matching pair, one was pasted with a stray character, or the key has been revoked. Create a new pair and paste both again.
* **A `Read:` check fails with 401/403.** The key's user has a role that can't view that kind of record. Raise the role (Admin sees everything), or stop that collector if you don't want it collected.
* **Health check passes but a table is empty.** Re-run that script and check the run log. **Requests**, **Reservations**, **Asset Maintenance** and **Verifications** are legitimately empty if your team doesn't use those Reftab features.

***

## Data Tables

Once the scripts run, these tables are created in your database. Each includes a `run_at` column for historical tracking, and a `raw` column holding the full record exactly as Reftab returned it, including fields not broken out into columns.

| Table | Source | Key Columns |
| - | - | - |
| `reftab_assets` | `GET /api/assets` | aid, title, category\_id, category\_name, location\_id, location\_name, status\_id, status\_name, status\_loanable, serial\_number, loan\_id, loanee\_email, loanee\_name, checked\_out\_at, due\_at, last\_scanned\_at, created\_at, loan\_period\_hours, notes, details, depreciation |
| `reftab_accessories` | `GET /api/accessories` | accid, title, type, location\_id, location\_name, vendor, barcode, order\_number, quantity, available, used, min\_quantity, purchase\_date, portal\_visible, notes, details |
| `reftab_categories` | `GET /api/categories` | cid, name, asset\_count, fields |
| `reftab_locations` | `GET /api/locations` (tree flattened) | clid, name, parent\_id, depth, address, email, main\_contact, can\_have\_assets, asset\_count, license\_count, expired\_license\_count, accessory\_count, low\_accessory\_count, notes |
| `reftab_licenses` | `GET /api/licenses?status=all` | licid, title, application\_id, vendor, licensee, seats, used, min\_seats, cost, location\_id, location\_name, order\_number, purchased\_at, expires\_at, cancelled\_at, terminated\_at, notification\_email, notes, details |
| `reftab_applications` | `GET /api/applications` | application\_id, name, vendor\_name, vendor\_website, category, status, website, cost, owner\_uids, owners, roles, license\_count, compliances, created\_source, created\_at, updated\_at, description |
| `reftab_loans` | `GET /api/loans` (once per status: out, in) | lid, loan\_group\_id, status, item\_type, aid, licid, accid, kid, title, category\_name, location\_id, location\_name, loanee\_id, loanee\_user\_id, loanee\_email, loanee\_name, loaner\_email, returner\_email, in\_at, out\_at, due\_at, application\_roles, notes, details |
| `reftab_loanees` | `GET /api/loanees` | person\_key, record\_type, lnid, uid, name, email, title, employee\_id, disabled, details |
| `reftab_users` | `GET /api/subusers` (disabled, then all) | uid, name, email, role, activated, disabled, role\_lock, details |
| `reftab_requests` | `GET /api/requests` (once per status) | rqid, status, requestor\_email, requestor\_name, email, uid, lnid, location\_id, location\_name, assigned\_to, start\_at, end\_at, reason, notes, items, asset\_ids, history, current\_approvers, details |
| `reftab_reservations` | `GET /api/reservations` (once per status) | resid, status, item\_type, aid, licid, accid, kid, title, location\_id, location\_name, loanee\_id, loanee\_user\_id, loanee\_email, loanee\_name, reserved\_by\_email, start\_at, end\_at, notes |
| `reftab_asset_maintenance` | `GET /api/assetmaintenance` (open, then completed) | amid, mnid, maintenance\_name, aid, asset\_title, completed, assigned\_uid, creator\_uid, assigned, start\_at, end\_at, due\_at, tasks |
| `reftab_verifications` | `GET /api/verifications` | vid, lid, status, loanee\_id, loanee\_user\_id, creator\_uid, created\_at, due\_at, submitted\_at, asset, accessory, kit, response, notes |

***

## Things worth knowing

**`serial_number` is read from your custom fields.** Reftab has no built-in serial field. Each asset category defines its own, so ConfigView takes the first field whose name contains "serial" (or is "S/N"). If your categories call it something else, it stays in `details` and `serial_number` is empty. The serial is what lets ConfigView match a Reftab asset to the same machine in Kandji, Intune or CrowdStrike.

**Loans and reservations cover every state, not just current ones.** Reftab's lists filter by status, so ConfigView asks for each status in turn. To find who has what **right now**, filter `reftab_loans` on `status = 'out'`, or read `loanee_email` on `reftab_assets`, which only shows the current borrower.

**Borrowers aren't necessarily Reftab users.** Reftab can lend equipment to people who never sign in. `reftab_loanees` lists both kinds together. `record_type` says which, and `person_key` keeps their two id spaces apart. `reftab_users` is the login accounts only.

**Disabled users are included and flagged.** `reftab_users.disabled = 1` marks accounts Reftab returned as disabled. Filter it out for current users.

**Thumbnails and image links aren't stored.** Reftab's image URLs expire after 15 minutes, so they'd be dead links by the time anyone read them.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.