Tango Contracts Inbound API
Generated fromTango Contracts Inbound API Integration Design Specification V0.4.docxin SharePoint folder04 Projects Integrations. OAS spec:contracts-inbound.yaml
Overview
Async REST API for posting contract records from a client system into Tango. The clientPUTs a batch of records; Tango returns an OK/Error envelope plus a gu_id, and the client polls the Status endpoint with that gu_id until processing finishes.
Owner: Tango Analytics
Spec version: 0.4
Status: Draft (auto-generated from design doc — needs review)
Base URLs
Authentication
Two required headers on every call:Endpoints
PUT /v1/suppliermgmt/batch/agreements
Submit a records array. Tango is async — the response only confirms acceptance.
Request (excerpt)
GET /v1/batch/status?gu_id=...
Three possible response shapes:
Integration logic
- Upsert key:
(supplier_site_number, contract_number). contract_amountis set on creation and is immutable afterwards.- Updates to total flow through
modification_amount, which is added to the existing modification amount (cumulative, not replacement). supplier_site_numbermust reference an existing supplier site in Tango — non-existent values are rejected.
Data model (required fields)
Validations (per source doc)
Open Questions / Assumptions
-
contract_statusaccepted values are not enumerated; sample shows"A"only. Confirm the full enum (Active, Closed, etc.). - Validation #15 references
tot_contract_amountbut the field is not in the schema — confirm whether this is the same asmax_contract_amountor a different field. - Date strings use
MM/DD/YYYYliteral; not ISO 8601. Confirm this is intentional vs. a doc convention. - Lookup values for
contract_statusandc_ext_lov01..10are marked<TBD>in the Appendix. - No explicit error response shape is defined for synchronous validation failures at the PUT endpoint — assumed errors come back via the polled status endpoint.

