This document provides an overview of the ACI Connetic APIs. In addition to client-initiated requests, these APIs are designed to facilitate the integration of ACI Connetic with banks' backend systems via a set of standardized interfaces. The following sections detail the available endpoints, data models, authentication methods, and usage guidelines to help you implement these APIs effectively
API Name: ACI Connetic APIs Version: API 1.0.0 API Design Standard: All APIs documented here conform to the OpenAPI Specification version 3.0.3.
All API requests are authenticated using OAuth 2.0. This ensures secure access and protects sensitive data across all endpoints. All APIs also enforce TLS encryption for secure data transmission across endpoints
APIs where ACI Connetic receives requests from an external system When an ACI Connetic microservice receives an API request from a customer’s system it will authorize the request using the OAuth 2.0 Client Assertion Flow (defined in https://datatracker.ietf.org/doc/html/rfc7521). ACI Connetic will use Service Accounts and Access Assignments to control what the customer can access.
The API Proxy is the unified entry point for API calls received by ACI Connetic. It serves as the initial gatekeeper for incoming requests and performs first-line validation of JWT access tokens — ensuring that a token is present, verifying its expiration status, and confirming that it was issued by a trusted authority.
Use Case: Bank Host wants to execute a Payment Initiation on ACI Connetic.
The Bank Host generates a signed JWT (Assertion Token) using the Service Account assigned to their Tenant\Bank. The Bank Host invokes ACI Connetics’ Access Token API on the API Proxy with the signed JWT (Assertion Token) serving as a credential for authentication The API Proxy forwards the request to the Access Control service The Access Control service verifies the JWT (Assertion Token) and returns a JWT (Access Token) The Bank Host invokes the Payment Initiation API on the Bank Channel HV microservice using the JWT (Access Token The Bank Channel HV microservice sends the JWT Access Token to the Access Control service for validation The Access Control service confirms the JWT (Access Token) is valid and authorized. The Bank Channel HV microservice proceeds with processing the Payment Initiation logic
When ACI Connetic is making an API request to a customers system it will authorize the request using the OAuth 2.0 Client Credentials Flow. The Client Credentials Flow (defined in OAuth 2.0 RFC 6749, section 4.4) involves an application exchanging its application credentials, such as client ID and client secret, for an access token
API Invocation Workflow Use Case: ACI Connetic wants to invoke a Posting API on the banks Core Banking platform.
The Posting microservice follows the OAuth 2.0 Client Credientials flow to request a JWT (Access Token) from the customers Authorization server. The request request includes client credentials and scopes. The external Authorization server verifies that the Client Credentials and scopes are valid and returns a JWT (Access Token) to ACI Connetic ACI Connetic will then invoke the external API providing the Access Token
ACI Connetic APIs follow a structured lifecycle - backward compatibility will be maintained across active versions to minimize disruption for consumers. APIs are versioned (see version tag in the appropriate yaml file), and new versions may be introduced with each major platform release. At any given time, ACI Connetic will support the latest version (N) and the two previous versions (N–1, N–2). Older versions beyond this window are deprecated with advance notice and a clear migration path. Deprecation timelines and changes are communicated via Release Notes
Refer to the YAML definition of the individual APIs for detailed field-level specifications. Note: these APIs does not support the full set of HTTP methods.
Explore APIs