​

Tango AP Inbound (Payment Confirmation) API

Generated from Tango AP Inbound API Integration Design Specification V1.2.docx in SharePoint folder 02 Lease Integrations. OAS spec: ap-inbound-api.yaml

​

Overview

​

Base URLs

​

Authentication

​

Endpoints

​

PUT /v1/leasemgmt/payments

{
  "records": [
    {
      "lease_payment_id": "80285",
      "invoice_header_id": "80285",
      "invoice_id": "80285",
      "invoice_number": "92492-023",
      "payment_status": "PAID",
      "check_number": "23499",
      "check_amount": "309.00",
      "check_date": "07/16/2020",
      "applied_amount": "309.00",
      "reconcile_date": ""
    }
  ]
}

{ "status": "OK/Error", "status_message": "", "gu_id": "cc70b809-5142-4ebe-9dcc-6ca59fa01122" }

​

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

​

Integration logic

• lease_payment_id is the record key — must already exist in Tango (it’s the same ID Tango sent in AP Outbound).
• Check Amount and Applied Amount may differ.
• A payment can be VOID either before the check is issued OR after it was PAID (retraction).
• Alternatively, the business may keep history by creating a credit invoice manually and marking the original payment VOID.

​

Data model

​

Validations

1. invoice_header_id is NULL → Invoice_header_id is null
2. lease_payment_id does not exist → lease_payment_id does not exist in Tango
3. payment_status is NULL → payment_status is null
4. payment_status not in (PAID, VOID) → payment_status does not match expected value
5. check_number is NULL → check_number is null
6. check_date is NULL → check_date is null
7. check_date format not MM/DD/YYYY → check_date does not match expected format

​

Open Questions / Assumptions

• Sample JSON sends numeric fields as strings ("check_amount": "309.00"). Schema uses number; consumers may need to coerce.
• No explicit response for synchronous errors at PUT — assumed errors flow through the polled status response.
• Lookup codes for payment statuses, etc., are <TBD> in source Appendix.

​

Changelog