> ## 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.

# Space hr inbound api

# Tango Space HR Inbound API

> Generated from `Tango Space HR Inbound API Integration Design Specification V1.8.docx` in SharePoint folder `03 Space Integrations`.
> OAS spec: [`space-hr-inbound-api.yaml`](./space-hr-inbound-api.yaml)

## Overview

Async REST API for posting Person/HR records into Tango. Drives Space Management's People records — assignments, schedules, hot-desking flags, building assignments.

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

## Endpoints

| Method | Path | Summary |
| - | - | - |
| PUT | `/v1/spacemgmt/batch/people` | Submit Person records (async). |
| GET | `/v1/batch/status?gu_id=...` | Poll processing status. |

Auth: `x-client` + `x-api-key`.

## Integration logic

* Upsert key: `person_number`.
* `total_office_days` is **computed by Tango** as the sum of `office_on_sun..sat` flags, regardless of any value sent in the JSON.
* `cost_center` is optional initially, BUT once an employee has been assigned to a department in Tango, it cannot subsequently be updated to NULL via this integration.
* Status-API response includes `processed_records` (success count) and `error_records` (failure count). Both are omitted from the JSON when their value would be zero.

## Data model (required ✅)

| Field | Type | Req | Notes |
| - | - | - | - |
| `person_number` | VARCHAR | ✅ | Employee Number; upsert key |
| `first_name` | VARCHAR | ✅ | |
| `middle_name` / `other_name` | VARCHAR | – | |
| `last_name` | VARCHAR | ✅ | |
| `employee_type` | VARCHAR | – | Lookup |
| `cost_center` | VARCHAR | – | See integration logic above |
| `title` | VARCHAR | – | "Position" |
| `building_assigned` | VARCHAR | – | Must exist in Tango |
| `manager_number` | VARCHAR | – | Valid person\_number |
| `shift_worker` ⚠ | VARCHAR | – | Y/N. **Field name vs label mismatch**: Client Label is "People Manager" |
| `status` | VARCHAR | ✅ | `Active` / `Inactive` |
| `country` | VARCHAR | ✅ | ISO code |
| `hire_date` / `end_date` ⚠ | DATE | – | Source types as `MM/DD/YYY` (3-digit year — typo) |
| `grade_level` | VARCHAR | – | Lookup |
| `work_from_home` | VARCHAR | – | Y/N |
| `primary_phone` | VARCHAR | – | "Work Phone" |
| `mobile_number` | VARCHAR | – | |
| `email` | VARCHAR | – | |
| `total_office_days` | NUMBER | – | Tango computes from daily flags |
| `office_on_sun..sat` | NUMBER | – | 0 / 1 flags |
| `cattr1..10` / `nattr1..5` / `dattr1..5` / `lovattr1..5` | – | – | Custom attributes |
| `brand_id` | NUMBER | – | |
| `seating_type` | VARCHAR | – | Lookup |
| `zip` | VARCHAR | – | |
| `mac_addresses` / `network_user_names` / `host_names` | VARCHAR | – | Comma-separated lists |

## Validations (sample)

1. `person_number` NULL → `required field: person_number is missing`
2. `first_name` NULL → `required field: first_name is missing or empty`
3. `last_name` NULL → `required field: last_name is missing or empty`
4. `cost_center` invalid → `cost_center: Invalid Cost Center '<data entered>'`
5. `shift_worker` not Y/N → `shift_worker has Invalid lookup code`
6. `status` not Active/Inactive → `status has Invalid status code`
7. `country` NULL/invalid → `country is missing or empty` / `Invalid country code`
8. Date format violations → `field <> value is not a valid date string`
9. `total_office_days` not numeric → `total_office_days value is not a number`
10. `office_on_*` not valid → `office_on_<day> value is not valid`

## Open Questions / Assumptions

* [ ] **`MM/DD/YYY` (3-digit year)** appears in source mapping for `hire_date`, `end_date`, and all `dattr*` fields. Almost certainly a typo — runtime likely uses `MM/DD/YYYY`. Confirm.
* [ ] **`shift_worker` field label mismatch**: Client Label is "People Manager" but field name is `shift_worker`. These are semantically different concepts; source doc may be conflating them.
* [ ] **Custom-attribute naming uses no underscores** (`cattr1`, `nattr1`, `dattr1`, `lovattr1`) — different from common-integrations conventions (`c_ext_attr1`).
* [ ] **`mac_addresses` / `network_user_names` / `host_names`** carry comma-separated lists in a VARCHAR — confirm length limits.
* [ ] **`brand_id` typed NUMBER** but other integrations carry brand names; reconcile.
* [ ] **Lookup codes** are `<TBD>` in Appendix.

## Changelog (compressed)

| Ver | Date | Description | Author |
| - | - | - | - |
| 0.1–1.7 | 2020-2025 | (see source doc — 17 revisions) | Various |
| 1.8 | 04/22/2026 | Updated API architecture diagram | Alpna Bansal |