Skip to main content

​
Overview

The old API used a single POST /v1/rent-reporting/report with all data in one flat request. The new API separates concerns:

​
Field mapping

​
Key behavioral differences

  1. Consumer PII submitted once — not with every payment report.
  2. Payment type is explicit — use child_support instead of cramming into rent_amount.
  3. Amounts are in cents — $4,500.00 = 450000. Multiply existing dollar values by 100.
  4. Status is auto-computed — don’t set account_status or payment_history_profile manually. They’re derived from payment records.
  5. GET endpoints exist — check submission status anytime via GET /submissions.
  6. Webhooks provide push notifications for bureau responses.
  7. Tradeline represents the obligation — created once, not re-sent with every payment.

​
Step-by-step migration

1

Create consumers

For each unique person in your system, call POST /consumers once. Save the returned id.
2

Create tradelines

For each ongoing payment obligation, call POST /tradelines with the consumer’s id and the correct payment_type. Save the returned tradeline id.
3

Report payments monthly

Each month, call POST /payments with the tradeline id, amount due, amount paid, and payment status.
4

Set up webhooks

Configure your webhook_url to receive bureau submission status updates.
5

Monitor submissions

Use GET /submissions to track bureau processing status.
6

Switch to production

Once integration testing is complete with sk_test_* keys, switch to sk_live_* for production.