Skip to main content
TransactIQ · API posture

API-first, by design

TransactIQ is an API product. A lender's credit engineering team integrates the analyzer into the underwriting pipeline and consumes signals as structured JSON outputs. This page describes the design posture partners can expect.

Endpoint-level documentation — URLs, request shapes, response schemas, and the full OpenAPI specification — is shared with customers under NDA, not published on this marketing site.

Design posture

Four commitments a CTO or credit engineering lead can rely on before seeing the specific endpoint shape.

Sync, async, and webhook modes

Small-volume real-time underwriting and large-volume batch portfolio analysis are different integration shapes. TransactIQ is designed to serve both — a synchronous mode for a single statement in the decisioning path, an asynchronous mode for batch submission with a poll-for-result pattern, and a webhook mode for push delivery into the lender's workflow queue.

Idempotent by design

Retries are normal in production integrations. TransactIQ treats the same input submitted twice as the same input — the second call returns the cached result rather than re-processing. This matters for billing predictability, latency bounds, and retry safety in the lender's reliability layer.

Versioned with explicit deprecation

Signal outputs evolve as underlying analytics improve. Every new signal or schema change ships under an explicit version tag; the previous version is supported for an announced deprecation window. Lenders do not find their integration broken by an overnight change.

RESTful JSON, language-neutral

The API surface is standard HTTPS + JSON — consumable from any language. SDK coverage is available for Python and Java, with sample repositories shared to customers under NDA. Neither SDK is a prerequisite — direct HTTP integration is fully documented.

Performance and reliability

Engineering posture on volume, latency, concurrency, and uptime. Specific numbers are deployment-tier- and contract-dependent, not marketing figures.

Batch volume

Architected for 10,000+ statements per day per tenant on the managed tier, with clean horizontal scaling on the self-hosted tier. Lenders processing higher volumes are onboarded with dedicated capacity planning.

Latency

Sync mode targets sub-minute round-trip for a typical retail borrower statement. Degraded inputs (scanned PSU, cooperative) take longer; the async mode is appropriate where latency is not the binding constraint.

Concurrency

Concurrent request handling scales with the deployment tier. Self-hosted tenants control their own concurrency envelope inside their VPC. Managed-tier concurrency targets are published in the integration runbook shared with customers.

Reliability posture

Target uptime SLA, incident communication path, and data-pipeline durability commitments are documented in the Master Service Agreement issued to each customer. Not a marketing claim — a contractual one.

Developer experience for customers

The posture above is design intent. The integration reality for a partner looks like this.

Sandbox access

A non-production sandbox with a representative set of statements and signal outputs is available to evaluating lenders during technical diligence. This is how the CTO and credit engineering lead validate fit before procurement, not after.

OpenAPI specification

A full OpenAPI specification describing the live endpoints, request shapes, response shapes, and error taxonomy is shared with partners under NDA. It is not a marketing page — it is the contract.

Integration runbook

A written runbook covering onboarding, authentication setup, rate-limit handling, error-handling patterns, idempotency key usage, and operational escalation paths — produced per partner, refined over the integration window.

Engineering partnership

Every customer integration is paired with a TransactIQ engineer for the integration window. Technical questions go to a person, not a support queue.

Ready to see the endpoint spec?

Customers receive the full OpenAPI specification, sandbox credentials, and a direct integration engineer through the evaluation and go-live window.

Request API sandbox access