Skip to main content

Tango Contracts Inbound API

Generated from Tango Contracts Inbound API Integration Design Specification V0.4.docx in SharePoint folder 04 Projects Integrations. OAS spec: contracts-inbound.yaml

Overview

Async REST API for posting contract records from a client system into Tango. The client PUTs 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)
Response — 200 OK

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

Three possible response shapes:

Integration logic

  • Upsert key: (supplier_site_number, contract_number).
  • contract_amount is 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_number must reference an existing supplier site in Tango — non-existent values are rejected.

Data model (required fields)

Validations (per source doc)

Open Questions / Assumptions

  • contract_status accepted values are not enumerated; sample shows "A" only. Confirm the full enum (Active, Closed, etc.).
  • Validation #15 references tot_contract_amount but the field is not in the schema — confirm whether this is the same as max_contract_amount or a different field.
  • Date strings use MM/DD/YYYY literal; not ISO 8601. Confirm this is intentional vs. a doc convention.
  • Lookup values for contract_status and c_ext_lov01..10 are 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.

Changelog (from source doc)