Skip to main content

​
Tango Lease Inbound API

Generated from Tango Lease Inbound API Integration Design Specification V0.5.docx in SharePoint folder 02 Lease Integrations. OAS spec: lease-inbound.yaml

​
Overview

Async REST API: client inserts/updates lease records and their child entities (Basic Info, Options & Terms, Contacts, Recurring Costs, Allocations, Obligations, Clauses). Async pattern with gu_id polling. Owner: Tango Analytics Spec version: 0.5 Status: Draft (auto-generated — needs review). Field-level mapping not extracted from source.

​
Base URLs

​
Authentication

Headers x-client + x-api-key.

​
Endpoints

​
Integration logic

  • Identification: either lease_id (Tango internal) OR the combination of lease_number + country + brand_id.
  • If the lease does not exist → error returned (this integration only updates).
  • If base lease info has any error, child entities are skipped entirely for that record.
  • If a child entity has an error, only that entity is skipped; rest of the record processes.
  • Comments and standard-language fields are trimmed to 4000 chars before save.
  • Async processing may be used for large payloads.

​
Validations (per source doc)

The source enumerates 61 validation rules grouped by entity. Required fields highlighted: Base lease identification (one identification method required):
  1. lease_number null → required field: lease_number is missing or invalid (required only if lease_id not provided)
  2. country null → same pattern (required only if lease_id not provided)
  3. brand_id null → same pattern (required only if lease_id not provided)
Date format: all date fields must be MM/DD/YYYY (validation #4 applies broadly). Conditional required fields by section: Lookup validations (must match Tango configured values): Duplicate check: if duplicate rows are found for any entity in the system → Duplicate <entity_name> rows found for lease xxxx

​
Open Questions / Assumptions

  • Field-level mapping is missing from the extracted text — the source doc references the data through tab screenshots that didn’t extract. The YAML uses additionalProperties: true so unknown fields are not rejected; a real consumer would need the full Tango field list from another source.
  • Multiple typos in source (per “Incorrect value” messages above) — preserved verbatim. Confirm whether the actual error strings are these or corrected versions.
  • Lookup validations all marked <TBD> — actual accepted values must come from Tango configuration.
  • Async semantics: the doc notes “Some of the APIs … could be asynchronous” — assumed all variants are async (matches the other PUT-style endpoints).
  • status_message value on success not specified.

​
Changelog