Skip to main content

Integration patterns - API, files, and manual touchpoints

AIS deployments usually combine programmatic access for high-volume flows with human steps where your policy requires judgment. The list below is typical, not a guarantee for every contract.

REST APIs (primary machine pattern)​

The Pro Gateway exposes a broad REST surface for lending, customers, scoring, portfolio views, exports, and related domains. Your mobile app, internet banking middleware, loan origination system, or enterprise service bus calls these endpoints over HTTPS.

  • Contract source: OpenAPI describes paths, methods, and schemas for the snapshot your AIS team publishes; use /openapi on this site as the technical appendix.
  • Base URL: AIS provides a base URL per environment (for example https://pro-gateway.sandbox.example vs https://pro-gateway.production.example). Do not assume a hostname from sample code in engineering repositories-confirm in your integration pack.

:::note Multiple gateways

Some programs use more than one HTTP entry point (for example a channel-specific gateway in addition to Pro). Your statement of work should name which gateway your integration targets. If you are unsure, ask your AIS account team.

:::

File-based and bulk flows​

Where product scope allows, banks may use structured file uploads (for example validated JSON or CSV bulk customer import) and asynchronous export jobs (create job → poll status → download). Availability and file formats are subject to your deployment and contract.

  • Treat file flows as batch integrations: plan for validation errors, partial success, and operator reruns.
  • Large extracts may be rate- or quota-limited like interactive APIs-coordinate peak loads with AIS.

Manual and UI-driven touchpoints​

Decision PRO supports review, approval, exception handling, and reporting in the browser. That is a valid “integration” for many banks alongside APIs: operations teams complete steps your core does not automate.

  • UI workflows do not replace systematic APIs for straight-through origination at scale; they complement them where human oversight is required.
  • Any download or export from the UI depends on role permissions and product configuration.

How Decision PRO talks to AIS (typical)​

In current product designs, the Decision PRO browser application uses the Pro Gateway as its primary HTTP upstream for login and most data (often through a small server layer in the app so secrets like server-only API keys are not shipped to end-user browsers). That is why HTTPS alignment and approved public hostnames matter for both Decision PRO and Pro-misaligned schemes (HTTPS app calling HTTP APIs) are blocked by browsers as mixed content. Confirm your environment diagram with AIS; do not infer hosts from engineering samples.

What is not assumed here​

  • Direct calls from the bank to every internal microservice (bypassing the gateway) are not the default bank integration model-routing stays inside AIS unless your architecture explicitly states otherwise.
  • Core banking posting, ledger settlement, and card schemes remain your systems; AIS focuses on credit intelligence and lending workflows aligned to your contract.

Next: Authentication concepts · Back: Overview