menu

Reference Materials

Format and protocol

Our APIs adhere to the following standard around format and protocol.

ElementStandard
Interaction PatternRequest / response
Communication ProtocolHTTPS with Mutual TLS
String Encoding FormatUTF-8 (Unicode Normalization Form C (NFC))
Request/Response FormatJSON / XML (for ISO-20022)
Methods SupportedGET, PUT, POST, DELETE
URL Scheme{TXB-base-url}/{version}/{service}/{resource-path}
info

Note

Version: The API version intended to be used. Service: The core service/product providing the functionality. resource-path: complete hierarchical path of the resource

  • Other items
    • kebab-case is used throughout in the URL
    • URLs generally use nouns, not verbs
    • Actions are determined by HTTP method used and request body of the post request (if required)
    • Depending on client needs, call-backs using WebHooks or similar approaches will also be considered

Environments available

TxB makes two environments available for our API users

Error behavior

TXB APIs respond with a small set of client actionable and universally well understood HTTP response codes. More granular level of information for error-scenarios is provided inside error objects

Response CodeMeaning
200Standard
400Bad request
401Unauthorized
403Forbidden
429Too many requests
500Server error

In case of non-successful processing of the request the TXB APIs respond with a non-200 HTTP response code.

  • These lie in 2 broad categories:
    • 4XX response: - Some issue with the request
    • 5XX response: - Some issue on the server side
info

Note

In case multiple errors are encountered, return a list of all errors. Returning all errors at once helps the users address them in smaller number of iterations.

In all non-success scenarios, the response body contains a list of error objects containing detailed information about what caused this error and how can it be resolved.

KeyTypeMandatoryDescription
errorCodeINT32YesUnique error code to identify precisely what sort of error occurred. Should be granular.
messageString (256 max)NoHuman readable message explaining the error
moreInfoString (256 max)NoRelevant link to more information and how to solve the error
retryBoolNoIndicates whether this requested can be replayed by client with expectation to succeed
retryAfterINT32NoTime in milliseconds after which client can retry the failed request
paramsObjectNoAdditional parameters about error (used for some specific error scenarios)

Field naming

The following naming conventions are used throughout for TXB APIs:

  • Field Names:
    • All field names are camelCased ASCII strings starting with a small cap alphabet or underscore
    • Examples: firstName, paymentAmount, dailyLimit, dailyLimit2, \_ext
  • Dates:
    • All date fields end with “Date” suffix
    • Examples: startDate, submissionDate, validityDate
  • Date-times:
    • All date-time fields end with “Time” suffix
    • Examples: paymentTime, acceptanceTime, completionTime
  • Identifiers:
    • All identifier fields end with “Id” suffix
    • Examples: paymentId, clientId, agentId

Field formats

  • Date and Date-time:
    • Only ISO8601 format is used to specify Date and Date-time Fields
    • Date Examples:
      • 2019-05-23, 1995-11-01, 2019-01-31
      • 2019-05-23T05:53:17Z, 1996-11-01T23:00:01Z
  • Boolean:
    • Only true/false values are used
    • Following formats are not used
      • true/false
      • 1/0
      • “Yes”/”No”
      • “Y”/”N”
  • JSON fields:
    • Only standard JSON field notations are used
    • Type casting like below examples are not used
      • “78” (Using strings in place of numbers)
      • “128.20” (Using strings in place of float)

Request headers

We support the below Request Headers

HeaderMandatorySupported valuesDefault value
AuthorizationNOTokensNA
AcceptNOapplication/json, application/xmlapplication/json
Content-TypeNOApplication/json, application/xmlApplication/json
  • Authorization header is non-mandatory as it holds additional information if required for additional authorization
  • If a non-mandatory header is not passed in the request, then its value is set to the default header value
  • Some additional security headers can also be required to be passed
  • Any additional headers passed with the request (besides the supported ones) are ignored by TXB APIs

Response headers

Response headers are included in the https response to provide additional information about the response sent. API users are expected to parse these responses headers to correctly interpret the response.

HeaderMandatoryPossible values
Content-TypeAlways with Response BodyApplication/json, application/xml
Content-EncodingAlways with Response BodyIdentity, deflate, gzip
X-API-VersionNoActual complete version of API responding
X-API-Deprecation-DateWith API versions planned for deprecationDate on which API will be marked deprecated
X-API-Deprecation-InfoWith API versions planned for deprecationAdditional information/documentation link on the deprecated API with possible upgrade options
  • Default String encoding: - UTF-8 (Unicode Normalization Form C (NFC))
  • Responses use their own encoding for content compression
  • Response encoding format is captured in “Content-Encoding” response header