Skip to main content

​
Tango Space Building and Floor Outbound API

Generated from Tango Space Building and Floor Outbound API Integration Design Specification V1.0.docx in SharePoint folder 03 Space Integrations. OAS spec: building-and-floor-outbound.yaml

​
Overview

Async delta REST API: client retrieves Building and Floor records updated in Tango since the last integration run. Single endpoint returns both entity types; type discriminates. Two-call pattern with gu_id and pagination (5000/page). Owner: Tango Analytics Spec version: 1.0 Status: Draft (auto-generated — needs review)

​
Base URLs

​
Authentication

Headers x-client + x-api-key.

​
Endpoints

​
Integration logic

  • Delta API: only records updated since last integration run.
  • Updates to building_id, floor_id, or lease_number do NOT trigger export — only other-field updates do.
  • type discriminates BUILDING vs FLOOR. Floor-specific fields populate only when type=FLOOR.
  • Null fields are omitted from response JSON.

​
Data model (selected — full list in YAML)

The schema has 150+ fields. Key groups:
  • Identity: type, building_id, building_number (Store Number), building_name (Store Name), floor_id, floor_number, floor_name, status
  • Location: address, address2, city, state, zip, county, country_code, latitude, longitude
  • Lease / management: lease_number, lease_exp_date, operations_manager, real_estate_manager
  • Classification: facility_type, ownership_type, contractual_type, measurement_type, occupancy_status, allocation_type, charge_type, bld_finance_grp, territory, timezone
  • Building attributes: delivery, dining_area, is_subleased, building_desc, building_rating, loading_dock, generator, purchase_date
  • Area metrics (sqft + sqm pairs): total_area_*, external_gross_*, internal_gross_*, cad_rentable_*, lease_rentable_*, lease_rentable_manual_*, usable_*, actual_*, vertical_penetration_*, property_common_*, building_common_*, floor_common_*, floor_shared_*, building_shared_*, residual_*, subleased_*, vacant_*
  • Workstation metrics (per type: dedicated / flex / shift / hotel): *_wkst_area_sf, *_wkst_area_sm, *_wkst_capacity, *_wkst_occupancy, *_wkst_occ_rate, *_wkst_count
  • Density / rollups: area_per_wkst, vacancy_pct, wkst_density, total_capacity, total_headcount, workstation_headcount, workstation_capacity, pct_building, capacity_available, capacity_planned
  • Parking: parking_spots_total, parking_spots_hc, parking_spots_ev, parking_spots_res
  • Cost: yearly_operating_cost, total_ownership_cost, tco_per_wkst, tco_per_capacity
  • Extension attributes: c_ext_attr1..10, n_ext_attr1..10 ⚠, d_ext_attr1..10, c_ext_lov1..10

​
Open Questions / Assumptions

  • Source typo n_ext-attr1 (hyphen between ext and attr) appears in the sample JSON. Preserved verbatim in description; runtime almost certainly uses underscore (n_ext_attr1). Confirm.
  • Direction header inconsistency: source says Source: CLIENT SYSTEM but content is outbound from Tango. Treated as outbound.
  • No required-field column in source data mapping — schema marks no fields required.
  • status values not enumerated — sample shows OP (operational?); confirm full enum.
  • Missing commas in source sample JSON (many lines lack trailing commas) — these are doc-typos, not wire format requirements.
  • No Address1 field in JSON — mapping uses address (no 1 suffix) while Client Label is “Address1”.
  • No validations documented in source.
  • Lookup codes are <TBD> in Appendix.

​
Changelog (compressed)