Build a fully custom borrower experience
on the VectraLMS API.

Manage subscriptions on the company API (company API key + X-User-UUID, webhooks permission):

# Register an endpoint — the signing secret is returned ONCE
curl -X POST https://api.example.com/api/v1/webhooks \
  -H "X-API-Key: <company-api-key>" \
  -H "X-Company-UUID: <company-uuid>" \
  -H "X-User-UUID: <your-user-uuid>" \
  -d '{"url":"https://you.example.com/hooks","events":["loan.created","payment.received"]}'
# → 201 { "webhook_uuid":"…", "secret":"whsec_…", "events":[…], "is_active":true }

# GET /api/v1/webhooks · GET/PUT/DELETE /api/v1/webhooks/{uuid} (secret never returned again)
# POST /api/v1/webhooks/{uuid}/rotate-secret  → returns a fresh secret once
# POST /api/v1/webhooks/{uuid}/test           → queues a signed "ping" delivery
# GET  /api/v1/webhooks/{uuid}/deliveries     → delivery history (status, response, attempts)

Events

loan.created · loan.updated · loan.paid_off · payment.received · payment.voided · application.submitted · application.decided · application.withdrawn · rewards.earned · rewards.redeemed · rewards.reversed · held_check.created · held_check.presentment_requested · lease.created · lease.item_returned · lease.item_swapped · lease.item_owned · lease.repossessed · lease.terminated · lease.reinstated

Store-register consumers: held_check.created lists a deferred-presentment check the register should take into custody (custody_state awaiting until it posts POST /api/v1/loans/{uuid}/held-checks/{uuid}/custody), and held_check.presentment_requested asks it to release the paper. The lease.* events carry every merchandise item with its inventory_item_uuid so register inventory can flip on_lease from the agreement's lifecycle; lease.item_swapped names swapped_item_uuid and replacement_item_uuid.

The payment events carry reconciliation fields for POS/register consumers: transaction_uuids (the ledger rows the payment created), payment_method_label, store_uuid, and — when the payment was posted with an external reference — external_source + external_ref (your system's transaction id, echoed back so you can match the event to your own ledger). payment.voided fires once per voided row, including for the payment-group void; correlate on transaction_uuids or external_ref to detect a full reversal. When a payment is posted with posted_by (the register teller who physically took the money), payment.received carries it and each payment.voided carries the original posting's posted_by recovered from the voided row.

Verifying deliveries

Each POST carries X-Webhook-Signature: sha256=<hex> — the HMAC-SHA256 of the raw request body using your endpoint's secret. Recompute it and compare (constant-time) before trusting the payload. The JSON envelope is versioned and carries a unique event_id — dedupe on it, since at-least-once delivery means retries can repeat. All money is integer cents.

Delivery & retries

Respond with any 2xx and process asynchronously on your side. On failure we retry intelligently:

• Transient failures (timeouts, 5xx, 429) retry with exponential backoff + jitter — ~30s doubling up to a 6h cap — for up to ~3 days before giving up.
• We honor a Retry-After header on 429/503 (capped).
• Permanent errors (4xx other than 408/429 — e.g. 400/401/404) are not retried; fix the endpoint and we'll deliver the next event (or use operator Redeliver).
• If an endpoint fails every recent delivery over a sustained period (not a brief blip) it is auto-suspended (stops receiving new events) so we don't hammer a dead URL; re-enable it via PUT /api/v1/webhooks/{uuid} once it's healthy. In-flight retries continue meanwhile.

• URL-versioned. Every endpoint lives under /api/v1/. A future incompatible revision ships under a new prefix (/api/v2/) — v1 keeps working.
• Additive changes are non-breaking and can ship at any time within v1: new endpoints, new response fields, and new enum values. Design your client to ignore unknown JSON fields so these never break you.
• Breaking changes are announced first. Before an endpoint or field is retired we send the Deprecation and Sunset response headers for a deprecation window, and note it in the changelog below.
• Consistent shapes. Errors are RFC 7807 application/problem+json with stable machine codes. Every list returns the same envelope: { items, count, limit, offset, has_more } — page by bumping offset until has_more is false.
• Money is integer cents. All amounts are *_cents int64 — never floats.

Changelog

• 2026-10-09 — Register custody and counter receipts: POST /api/v1/loans/{uuid}/title-fee-receipt (+ /void) posts the counter receipt for cash-at-origination title fees on a register-owned company (the origination refuses a direct receipt with 422 cash_tender_register_owned and originates with the receipt pending; exactly-once per external_ref); POST .../held-checks/{uuid}/custody and .../custody/release record which register instrument holds a deferred-presentment check (GET .../held-checks?custody=awaiting|held|released); new webhook events held_check.* and lease.* (merchandise carries inventory_item_uuid).
• 2026-07-21 — Staff API register bridge: optional posted_by operator attribution ({external_id, name}, max 64/128 — 422 invalid_posted_by beyond) on POST /api/v1/loans/{uuid}/payments and the payment-group void. Persisted in each created ledger row's metadata_json, echoed on the payment response, carried on payment.received (and, from the voided rows, on payment.voided), and appended to the maker line on approval-queue rows (API key user <uuid> — posted by <name>) so checkers see the human operator behind the key.
• 2026-07-20 — Staff API register bridge: POST /api/v1/loans/{uuid}/payments accepts external_source/external_ref/external_display (hard exactly-once backstop per external transaction — duplicates get 409 external_ref_conflict with the original posting's transaction_uuids) and a point-of-receipt store_uuid; typed machine codes on payment errors (loan_not_found, loan_not_payable, invalid_amount, invalid_method, idempotency_conflict, external_ref_conflict, approval_pending, retryable 5xx); payment-group void (POST .../payments/void, idempotent, maker-checker aware) + group status poll (GET .../payments/{key}); teller lookup filters on GET /api/v1/loans (loan_number= exact, q= borrower search); staff GET /api/v1/stores; payment.received/payment.voided webhooks now carry external_source/external_ref.
• 2026-07-04 — Servicing: authoritative payoff quote, autopay pause/resume, credit-limit-increase requests, transaction disputes, hardship/modification requests, and secure two-way messaging. Per-IP rate limiting on all pre-auth endpoints.
• 2026-07-03 — Loan documents & per-transaction receipts (PDF), statement PDF download, product catalog and store discovery, and public lead/affiliate application intake with source attribution.
• 2026-07 — Initial v1: auth & 2FA, profile/addresses/phones, loans/transactions/statements, payment methods, payments, scheduled payments, autopay, notifications, uploaded documents & e-signature requests, applications.