Beyond Finance API integration services (OpenData / OpenFinance)

Enrolled debt portfolio sync

One call returns the full set of enrolled accounts with creditor name, account reference, enrolled balance, current balance, status (negotiating, settled, paid), and the active settlement offer. Concrete use: a credit-coaching platform refreshes a client’s "debts remaining vs. settled" widget every night without screen scraping.

Trust account ledger export

Reads the Dedicated Account history — each scheduled draft, cleared deposit, settlement disbursement, and program fee — with running balance. Concrete use: a bookkeeper imports the ledger into QuickBooks or a spreadsheet to reconcile what the client paid against what creditors received.

Scheduled activity feed

Returns upcoming items: next draft date and amount, planned settlement payouts, and the projected graduation month. Concrete use: a personal-finance app posts a "heads-up: $312 draft on the 14th" reminder so the client keeps enough in the funding account.

Negotiation milestone webhooks

Subscribe to events — settlement.offer_received, settlement.accepted, debt.paid_in_full, draft.returned. Concrete use: a case-management system opens a task for an advisor the moment a creditor offer lands instead of polling hourly.

Additional-deposit API

The app lets clients add money to the Dedicated Account to settle faster; the endpoint accepts a one-off contribution request and returns the updated draft schedule and revised graduation estimate. Concrete use: a "round-up savings" app sweeps spare change into the escrow account weekly.

Progress & savings reporting

Aggregates total enrolled debt, total resolved, total saved, fees to date, and percent complete into a single report object. Concrete use: a financial-wellness benefit inside an employer HR portal shows enrolled employees an anonymised progress score.

1. Personal-finance app: unified debt view

Business context: a budgeting app wants to show a user’s debt-resolution program next to their bank and card balances. Data / API: GET /v1/beyond/enrolled-debts plus GET /v1/beyond/progress. OpenData / OpenFinance mapping: the same consumer-permissioned pattern the CFPB Section 1033 framework describes for bank data — the client authorizes, the aggregator pulls, the budgeting app renders; nothing moves without consent.

2. Bookkeeper / accountant: trust-account reconciliation

Business context: an accountant managing a client’s finances needs to tie every Dedicated Account draft to a settlement or fee. Data / API: POST /v1/beyond/trust-account/statement with a date range, returning ledger lines with type and running_balance; export as CSV. Mapping: statement export is the OpenBanking "account information" use case applied to an escrow ledger rather than a checking account.

3. Advisor case management: real-time milestones

Business context: a debt-coaching firm wants advisors notified the instant a creditor offer arrives. Data / API: webhook subscription to settlement.offer_received and settlement.accepted; payload carries account_id, offer_amount, creditor, expires_at. Mapping: event-driven OpenFinance — push notifications replace polling, mirroring how PSD2/Section 1033-style platforms expose change events.

4. Lender pre-qualification: verified progress

Business context: a lender evaluating a borrower near program graduation wants a verified "X% complete, $Y saved, est. graduation September" snapshot instead of a screenshot. Data / API: a signed, time-stamped progress object from GET /v1/beyond/progress?signed=true. Mapping: consumer-permissioned data sharing for credit decisioning — an explicit OpenData use case in the Section 1033 rulemaking.

5. Employer financial-wellness benefit

Business context: an HR platform offers debt-relief support and wants an aggregate, de-identified view of enrolled employees’ progress. Data / API: per-user progress calls behind employee consent, aggregated server-side into cohort metrics. Mapping: data-minimization in practice — only the percent-complete and savings figures leave the boundary; account numbers and creditor names never do.

Authorized login & token refresh

// Step 1 - exchange authorized client credentials for a session
POST /v1/beyond/auth/login
Content-Type: application/json

{
  "username": "client@example.com",
  "password": "<authorized-secret>",
  "device_id": "of-lab-connector-01",
  "consent_id": "cns_8f21a0"
}

// 200 OK
{
  "access_token": "eyJhbGci...",
  "refresh_token": "rt_b71c...",
  "expires_in": 900,
  "program_id": "BP-4471902"
}

// Step 2 - refresh before expiry
POST /v1/beyond/auth/refresh
{ "refresh_token": "rt_b71c..." }

Trust account statement query

POST /v1/beyond/trust-account/statement
Authorization: Bearer <ACCESS_TOKEN>
Content-Type: application/json

{
  "program_id": "BP-4471902",
  "from_date": "2026-01-01",
  "to_date": "2026-04-30",
  "page": 1,
  "page_size": 100
}

// 200 OK
{
  "balance": 1284.55,
  "currency": "USD",
  "items": [
    { "date": "2026-04-14", "type": "draft",        "amount":  312.00, "running_balance": 1284.55 },
    { "date": "2026-03-28", "type": "disbursement",  "amount": -640.00, "running_balance":  972.55, "creditor": "Acme Bank" },
    { "date": "2026-03-14", "type": "draft",         "amount":  312.00, "running_balance": 1612.55 }
  ],
  "page": 1, "page_size": 100, "has_more": true
}

Enrolled debts + error handling

# Python client snippet
import requests

r = requests.get(
    "https://api.example.com/v1/beyond/enrolled-debts",
    headers={"Authorization": f"Bearer {token}"},
    params={"program_id": "BP-4471902"},
    timeout=20,
)
if r.status_code == 401:
    token = refresh(token)            # re-auth and retry once
elif r.status_code == 429:
    sleep(int(r.headers.get("Retry-After", "5")))
r.raise_for_status()

for debt in r.json()["debts"]:
    print(debt["creditor"], debt["current_balance"], debt["status"])

# error body shape
# { "error": "rate_limited", "message": "Too many requests", "retry_after": 5 }

Negotiation webhook delivery

POST https://your-app.example.com/webhooks/beyond
X-OFLab-Signature: sha256=2b7c...    // HMAC over the raw body
Content-Type: application/json

{
  "event": "settlement.offer_received",
  "program_id": "BP-4471902",
  "account_id": "acct_55120",
  "creditor": "Acme Bank",
  "offer_amount": 640.00,
  "original_balance": 1480.00,
  "expires_at": "2026-05-20T23:59:59Z",
  "occurred_at": "2026-05-12T14:03:11Z"
}

// respond 2xx within 5s; we retry with backoff up to 24h

Regulatory framing

Debt-resolution data is sensitive financial information, so every integration is built around a consent record and a documented authorization. In the United States the relevant frameworks include the CFPB’s Section 1033 personal financial data rights rule (finalized October 2024, with tiered compliance dates running from 2026 to 2030), the Gramm-Leach-Bliley Act and its Safeguards Rule for protecting consumer financial data, and the FTC Telemarketing Sales Rule provisions that govern debt-relief services. We align logging, retention, and disclosure handling with these. See the CFPB’s overview of personal financial data rights (Section 1033) and the general background on debt settlement.

What we do in practice

• Authorized or documented endpoints only — no credential resale, no bulk harvesting.
• Per-user consent IDs threaded through every request and stored with timestamps.
• Encryption in transit (TLS) and at rest; secrets in a managed vault, never in source.
• Data minimization — integrations request only the fields a scenario needs (e.g. progress percentages without creditor names).
• Access logs, revocation handling, and configurable retention windows; NDAs signed when required.

• National Debt Relief — one of the largest US debt-settlement firms; client portals hold enrolled-debt lists, savings-account balances, and settlement status, the same data shapes an aggregator would normalise alongside Beyond Finance.
• Freedom Debt Relief — reports more than a million customers and $20 billion settled; its dashboard exposes deposit history and per-creditor progress that map cleanly onto the trust-account and enrolled-debt endpoints described above.
• Americor — Irvine-based, founded 2009; combines debt settlement with a consolidation-loan product, so an integration often has to merge a settlement ledger with a loan amortisation schedule.
• Accredited Debt Relief — a Beyond Finance division; data structures overlap heavily, which makes it a natural candidate for a shared connector.
• New Era Debt Solutions — long-running settlement provider with a higher debt minimum; client records cover enrolled balances, escrow contributions, and completed settlements.
• Pacific Debt Relief — uses performance-based fees on settled amounts, so fee lines in its ledger need careful mapping during reconciliation work.
• JG Wentworth — expanded from structured settlements into debt relief in 2019; users may hold both annuity-payment and debt-program data worth unifying.
• CuraDebt — offers debt settlement plus tax-debt resolution; integrations may span consumer-debt and IRS/state-tax balances.
• DebtBlue — debt-settlement provider whose client area follows the familiar enrolled-debt, deposit-schedule, and settlement-status layout.
• TurboDebt — debt-relief marketplace that routes clients to settlement programs; useful context when consolidating data across multiple downstream providers.

Deliverables checklist

• API specification (OpenAPI / Swagger) for login, enrolled debts, trust account, scheduled activity, webhooks
• Protocol and auth-flow report (token issue / refresh / session and biometric gating chain)
• Runnable source for login and statement endpoints (Python / Node.js)
• Automated tests, sample payloads, and developer documentation
• Compliance guidance (consent records, retention, GLBA Safeguards alignment, Section 1033 framing)
• Optional hosted, pay-per-call API endpoint with usage metering

Engagement models

• Source-code delivery from $300 — you receive runnable API source code and full documentation; pay after delivery once you are satisfied.
• Pay-per-call API billing — call our hosted endpoints and pay only for the calls you make, no upfront fee; suited to teams that prefer usage-based pricing.

1. Scope confirmation — which data surfaces (enrolled debts, trust account, scheduled activity, progress) and which delivery model.
2. Protocol analysis and API design — 2–5 business days depending on complexity.
3. Build and internal validation — 3–8 business days, including auth, paging, rate-limit handling, and webhook receipt.
4. Documentation, sample code, and test cases — 1–2 business days.
5. First delivery typically lands in 5–15 business days; third-party approvals or real-time pipelines can extend it.

Contact

For a quote or to submit your target app and requirements, open our contact page:

Contact page

What do you need from me to start a Beyond Finance integration?

How long does delivery take?

How do you handle compliance and privacy for debt resolution data?

Do you provide runnable source code or only documentation?