Skip to main content

Tango Total Approved Budget Inbound API

Generated from Tango Total Approved Budget Inbound API Integration Design Specification V0.4.docx in SharePoint folder 04 Projects Integrations. OAS spec: total-approved-budget-inbound.yaml

Overview

Async REST API for posting approved budget totals into Tango. The same payload covers both Project and Lease budgets — populated identifier fields determine which branch applies. Async two-call pattern with gu_id. Owner: Tango Analytics Spec version: 0.4 Status: Draft (auto-generated from design doc — needs review)

Base URLs

Authentication

x-client and x-api-key headers, required on every call.

Endpoints

PUT /v1/projectmgmt/batch/budgets

Request — project mode
Request — lease mode
Response — 200 OK

GET /v1/batch/status?gu_id=...

Standard three-shape response (PROCESSING / COMPLETED / ERROR).

Integration logic

  • Project mode: budget template must be applied and available; budget rows are populated against the total-approved budget line.
  • client_ref_num is the client-specific unique reference to identify a budget line. Either client_ref_num OR line_item_seq must be sent.
  • If project baseline versioning is enabled, the data updates the draft baseline; once approved, a new baseline is created.
  • After the initial payload, subsequent total values are added to the existing amount (cumulative, not replacement).
  • Once a total is loaded, the project status is set to Approved.
  • Lease mode: the total approved rent amount can be loaded for the lease.

Data model (per-mode required flags)

Validations

Open Questions / Assumptions

  • OAS 3.1 cannot natively express the dual-mode required-field matrix — the schema enforces only the common baseline; runtime validation must add Project-mode and Lease-mode rules.
  • Validation #12 says client_ref_num is missing or empty unconditionally but the data-mapping says either client_ref_num OR line_item_seq is acceptable. Treating the validation as Project-mode-conditional based on data-mapping.
  • header_status enum: only APPROVED is listed as accepted; modeled as a single-value enum.
  • No explicit response for synchronous validation errors at the PUT endpoint — assumed errors land in the polled status response.
  • Sample value of line_item_seq is sent as "" in lease mode (empty string in a number field); modeled as oneOf number | empty string.
  • Baseline versioning side-effect: doc mentions a new baseline is created on approval — out of scope for the request schema but flagged so consumers know about the state change.

Changelog