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

# User roles reconcile nonbu

# Tango User Roles Reconcile API (non-BU)

> Generated from `Tango nonBU User Roles Reconcile API Integration Design Specification V0.7.docx` in SharePoint folder `01 Common Integrations`.
> OAS spec: [`user-roles-reconcile-nonbu.yaml`](./user-roles-reconcile-nonbu.yaml)

## Overview

Async outbound REST API: client retrieves Tango user accounts and their provisioning state for non-BU client environments. Mirrors the [BU variant](./user-roles-reconcile-bu.md) but without the Business Unit layer and with a flatter response shape.

**Owner:** Tango Analytics
**Spec version:** 0.7
**Status:** Draft (auto-generated — needs review)

## Differences from the BU variant

| Aspect | BU variant | non-BU variant |
| - | - | - |
| `default_bu` field | Present | **Removed** |
| `bu[]` array | Present | **Removed** |
| `brands` shape | Nested objects with audit fields | Flat comma-separated string |
| `countries` shape | Separate `country[]` with nested audit | Inline under user with `countries[].entity_security[]` |
| Page size | 1000 | 5000 |
| Endpoint | `/v1/usermgmt/batch/users` | Same |

## Base URLs

| Environment | URL |
| - | - |
| Production | `https://api.tangoanalytics.com` |
| Test (SIT/UAT) | `https://testapi.tangoanalytics.com` |

## Authentication

Headers `x-client` + `x-api-key`.

## Endpoints

| Method | Path | Summary |
| - | - | - |
| GET | `/v1/usermgmt/batch/users` | Initiate user export — returns `gu_id`. |
| GET | `/v1/batch/status?gu_id=...&page_no=...` | Retrieve paginated records. |

## Filter parameters (mutually exclusive)

| Param | Notes |
| - | - |
| *(none)* | All users. |
| `user_name` | Specific user. |
| `status` | Users with the given status. |

## Integration logic

Same as the BU variant — batch refresh once per day; data API invokable at most once per day. Status polling unrestricted.

## Data model

Per-user record:

```json theme={null}
{
  "user_name": "test.user@abc.com",
  "first_name": "test",
  "last_name": "user",
  "email": "test.user10.04.22@abc.com",
  "user_type": "CORPORATE",
  "sso": "Y",
  "status": "A",
  "default_country": "USA",
  "data_access_level": "F",
  "brands": "Tango Standard",
  "countries": [
    {
      "country": "USA",
      "regions": "ALL",
      "roles": " ",
      "entity_security": [
        { "entity_type": "TARGET", "full_access": "Y", "restrictions": [] },
        { "entity_type": "SITE",   "full_access": "Y", "restrictions": [] },
        { "entity_type": "STORE",  "full_access": "Y", "restrictions": [] },
        { "entity_type": "PROJECT","full_access": "Y", "restrictions": [] },
        { "entity_type": "LEASE",  "full_access": "Y", "restrictions": [] }
      ]
    }
  ]
}
```

## Open Questions / Assumptions

* [ ] **`brands` field is a flat string** (`"Tango Standard"`) per the source sample. The BU variant has it as a nested-object array. Asymmetric shapes between BU and non-BU variants — confirm intended.
* [ ] **`roles` field sample value is `" "`** (single space). Likely empty access on this sample; confirm whether real records carry role lookup codes here.
* [ ] **`entity_type` values** include `TARGET`, `SITE`, `STORE`, `PROJECT`, `LEASE` — the BU variant lists `TARGET`, `SITE`, `LEASE` etc. Confirm the complete enum.
* [ ] **No audit fields** (`creation_date` / `last_login_date` etc.) in the non-BU response — the BU variant added these in v0.6. Confirm whether they should be present here too.

## Changelog

| Ver | Date | Description | Author |
| - | - | - | - |
| 0.1–0.6 | 2022-2024 | (see source doc) | Various |
| 0.7 | 04/23/2026 | Updated API architecture diagram | Alpna Bansal |