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

# Asset details outbound

# Tango Asset Details Outbound API

> Generated from `Tango Asset Details Outbound API Integration Design Specification V1.0.docx` in SharePoint folder `01 Common Integrations`.
> OAS spec: [`asset-details-outbound.yaml`](./asset-details-outbound.yaml)

## Overview

Async **delta** REST API: client retrieves asset detail records that were created/updated in Tango since the last integration run. Two-call pattern with `gu_id`; null fields are omitted from the response JSON.

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

## 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/assetmgmt/delta/assetdetails` | Initiate delta asset export — returns `gu_id`. |
| GET | `/v1/batch/status?gu_id=...` | Retrieve asset records. |

## Integration logic

* Delta semantics: only records updated after the last integration run are returned.
* Same `gu_id` may be polled multiple times for the same record set.
* Null/unconfigured fields are omitted from the response.

## Data model

The source data-mapping table does NOT mark any field as required for the outbound direction. All fields are emitted only when populated in Tango.

| Field | Type | Notes |
| - | - | - |
| `asset_instance_id` | NUMBER | |
| `asset_instance_number` / `asset_instance_name` / `asset_master_number` | VARCHAR | |
| `description` | VARCHAR | |
| `serial_number` / `Tag_number` ⚠ / `manufacturer` / `Model_no` ⚠ | VARCHAR | Mapping uses inconsistent case (`Tag_number`, `Model_no`); sample JSON uses lowercase |
| `date_in_service` / `warranty_exp_date` / `date_of_purchase` / `warranty_start_date` | DATE `MM/DD/YYYY` | |
| `purchage_value` ⚠ | NUMBER | **Typo in source** (should likely be `purchase_value`) |
| `net_book_value` / `monthly_lease_payment` | NUMBER | |
| `comments` / `vendor` | VARCHAR | |
| `lease_begin_date` / `lease_end_date` | DATE | |
| `leasing_company` ⚠ | DATE → string | Source types as DATE but content suggests string |
| `status` / `asset_type` / `model_name` / `asset_owner` / `associated_entity_type` / `used_by_entity_type` / `associated_entity_number` / `used_by_entity_number` | VARCHAR | |
| `used_by_entity_id` | NUMBER | |
| `useful_life` / `depreciation` / `warranty_period` | NUMBER | |
| `property_number` ⚠ / `building_number` ⚠ | VARCAHR → VARCHAR | Mapping types as `VARCAHR` (typo); treated as string |
| `floor_number` | VARCHAR | |
| `last_update_date` | TIMESTAMP | Date the record was updated |
| `last_updated_by` | VARCHAR | Process or user that updated the record |
| `c_ext_attr1..27` | VARCHAR | Custom string attributes |
| `n_ext_attr1..10` | NUMBER | Custom number attributes |
| `d_ext_attr1..5` | DATE | Custom date attributes |

## Open Questions / Assumptions

* [ ] **Source typo `purchage_value`** — almost certainly should be `purchase_value`. The inbound spec uses the correct spelling, creating an asymmetry. Confirm with API team.
* [ ] **Field case inconsistency** between mapping table and sample JSON: `Tag_number` vs `tag_number`, `Model_no` vs `model_no`. Preserved per mapping; verify actual wire format.
* [ ] **Data type typo `VARCAHR`** appears for `property_number` and `building_number`. Treated as VARCHAR.
* [ ] **`leasing_company` typed DATE** but contents are strings (e.g., a company name). Schema uses string.
* [ ] **No required-field annotation** for the outbound direction.

## Changelog

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