Skip to main content

Integration architecture

The integration layer standardizes how the platform connects to external systems.

13.1 Synchronous integrations

Used when a real-time answer is required in the user journey or servicing flow, for example:
  • KYC/KYB screening results
  • sanctions and PEP screening status
  • bureau and decision calls
  • balance or account verification through open banking
  • document package creation and e-signature initiation

13.2 Asynchronous integrations

Used for non-blocking, high-volume or long-running processes, for example:
  • communication delivery updates
  • data warehouse feeds
  • CRM synchronization
  • decision callbacks
  • batch regulatory extracts
  • collections platform updates
  • audit and event consumption by downstream systems

13.3 General ledger and accounting integration

Finpace maintains product-domain accounting context and publishes posting events or journal-ready records. Final booking into the enterprise general ledger remains configurable. This keeps the product services independent from a single finance stack while preserving the accounting trace required for reconciliation.

API conventions

TopicConvention
Resource modelResource-oriented REST endpoints under /v1 with stable identifiers and explicit lifecycle actions where required.
Payload formatJSON over HTTPS for synchronous APIs. Webhooks publish JSON payloads signed with HMAC.
AuthenticationOAuth 2.0 client credentials for server-to-server integrations and authorization code flow for delegated user journeys.
IdempotencyPOST endpoints that create or trigger financial actions accept Idempotency-Key headers and return the original result on safe retry.
TraceabilityX-Request-Id and X-Correlation-Id may be supplied by the caller and are echoed in downstream audit records.
PaginationCollection resources use pageSize and pageToken rather than offset pagination.
VersioningBackward compatible changes are additive within a major version. Breaking changes are released on a new base path.
Error modelErrors follow a problem-details style response with machine-readable codes and field-level validation detail.