Skip to main content

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

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

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 ✅)

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)