Libraries tagged by date firma

The Inter TT REST API is described using OpenAPI 3.0. The descriptor for the api can be downloaded in both [YAML](http://localhost:8080/cyclos/api/openapi.yaml) or [JSON](http://localhost:8080/cyclos/api/openapi.json) formats. These files can be used in tools that support the OpenAPI specification, such as the [OpenAPI Generator](https://openapi-generator.tech). In the API, whenever some data is referenced, for example, a group, or payment type, either id or internal name can be used. When an user is to be referenced, the special word 'self' (sans quotes) always refers to the currently authenticated user, and any identification method (login name, e-mail, mobile phone, account number or custom field) that can be used on keywords search (as configured in the products) can also be used to identify users. Some specific data types have other identification fields, like accounts can have a number and payments can have a transaction number. This all depends on the current configuration. ----------- Most of the operations that return data allow selecting which fields to include in the response. This is useful to avoid calculating data that finally won't be needed and also for reducing the transfer over the network. If nothing is set, all object fields are returned. Fields are handled in 3 modes. Given an example object `{"a": {"x": 1, "y": 2, "z": 3}, "b": 0}`, the modes are: - **Include**: the field is unprefixed or prefixed with `+`. All fields which are not explicitly included are excluded from the result. Examples: - `["a"]` results in `{"a": {"x": 1, "y": 2, "z": 3}}` - `["+b"]` results in `{"b": 0}` - `["a.x"]` results in `{"a": {"x": 1}}`. This is a nested include. At root level, includes only `a` then, on `a`'s level, includes only `x`. - **Exclude**: the field is prefixed by `-` (or, for compatibility purposes, `!`). Only explicitly excluded fields are excluded from the result. Examples: - `["-a"]` results in `{"b": 0}` - `["-b"]` results in `{"a": {"x": 1, "y": 2, "z": 3}}` - `["a.-x"]` results in `{"a": {"y": 2, "z": 3}}`. In this example, `a` is actually an include at the root level, hence, excludes `b`. - **Nested only**: when a field is prefixed by `*` and has a nested path, it only affects includes / excludes for the nested fields, without affecting the current level. Only nested fields are configured. Examples: - `["*a.x"]` results in `{"a": {"x": 1}, "b": 0}`. In this example, `a` is configured to include only `x`. `b` is also included because, there is no explicit includes at root level. - `["*a.-x"]` results in `{"a": {"y": 2, "z": 3}, "b": 0}`. In this example, `a` is configured to exclude only `x`. `b` is also included because there is no explicit includes at the root level. For backwards compatibility, this can also be expressed in a special syntax `-a.x`. Also, keep in mind that `-x.y.z` is equivalent to `*x.*y.-z`. You cannot have the same field included and excluded at the same time - a HTTP `422` status will be returned. Also, when mixing nested excludes with explicit includes or excludes, the nested exclude will be ignored. For example, using `["*a.x", "a.y"]` will ignore the `*a.x` definition, resulting in `{"a": {"y": 2}}`. ----------- For details of the deprecated elements (operations and model) please visit the [deprecation notes page](https://documentation.cyclos.org/4.16.3/api-deprecation.html) for this version.

Go to Download

RESTful API for Account Information Services (AIS) and Payment Initiation Services (PIS) Application Version: 2.29.4 The following pages give you some general information on how to use our APIs. The actual API services documentation then follows further below. You can use the menu to jump between API sections. This page has a built-in HTTP(S) client, so you can test the services directly from within this page, by filling in the request parameters and/or body in the respective services, and then hitting the TRY button. Note that you need to be authorized to make a successful API call. To authorize, refer to the 'Authorization' section of the API, or just use the OAUTH button that can be found near the TRY button. General information Error Responses When an API call returns with an error, then in general it has the structure shown in the following example: { "errors": [ { "message": "Interface 'FINTS_SERVER' is not supported for this operation.", "code": "BAD_REQUEST", "type": "TECHNICAL" } ], "date": "2020-11-19T16:54:06.854+01:00", "requestId": "selfgen-312042e7-df55-47e4-bffd-956a68ef37b5", "endpoint": "POST /api/v2/bankConnections/import", "authContext": "1/21", "bank": "DEMO0002 - finAPI Test Redirect Bank (id: 280002, location: none)" } If an API call requires an additional authentication by the user, HTTP code 510 is returned and the error response contains the additional "multiStepAuthentication" object, see the following example: { "errors": [ { "message": "Es ist eine zusätzliche Authentifizierung erforderlich. Bitte geben Sie folgenden Code an: 123456", "code": "ADDITIONAL_AUTHENTICATION_REQUIRED", "type": "BUSINESS", "multiStepAuthentication": { "hash": "678b13f4be9ed7d981a840af8131223a", "status": "CHALLENGE_RESPONSE_REQUIRED", "challengeMessage": "Es ist eine zusätzliche Authentifizierung erforderlich. Bitte geben Sie folgenden Code an: 123456", "answerFieldLabel": "TAN", "redirectUrl": null, "redirectContext": null, "redirectContextField": null, "twoStepProcedures": null, "photoTanMimeType": null, "photoTanData": null, "opticalData": null, "opticalDataAsReinerSct": false } } ], "date": "2019-11-29T09:51:55.931+01:00", "requestId": "selfgen-45059c99-1b14-4df7-9bd3-9d5f126df294", "endpoint": "POST /api/v2/bankConnections/import", "authContext": "1/18", "bank": "DEMO0001 - finAPI Test Bank" } An exception to this error format are API authentication errors, where the following structure is returned: { "error": "invalid_token", "error_description": "Invalid access token: cccbce46-xxxx-xxxx-xxxx-xxxxxxxxxx" } Paging API services that may potentially return a lot of data implement paging. They return a limited number of entries within a "page". Further entries must be fetched with subsequent calls. Any API service that implements paging provides the following input parameters: • "page": the number of the page to be retrieved (starting with 1). • "perPage": the number of entries within a page. The default and maximum value is stated in the documentation of the respective services. A paged response contains an additional "paging" object with the following structure: { ... , "paging": { "page": 1, "perPage": 20, "pageCount": 234, "totalCount": 4662 } } Internationalization The finAPI services support internationalization which means you can define the language you prefer for API service responses. The following languages are available: German, English, Czech, Slovak. The preferred language can be defined by providing the official HTTP Accept-Language header. finAPI reacts on the official iso language codes "de", "en", "cs" and "sk" for the named languages. Additional subtags supported by the Accept-Language header may be provided, e.g. "en-US", but are ignored. If no Accept-Language header is given, German is used as the default language. Exceptions: • Bank login hints and login fields are only available in the language of the bank and not being translated. • Direct messages from the bank systems typically returned as BUSINESS errors will not be translated. • BUSINESS errors created by finAPI directly are available in German and English. • TECHNICAL errors messages meant for developers are mostly in English, but also may be translated. Request IDs With any API call, you can pass a request ID via a header with name "X-Request-Id". The request ID can be an arbitrary string with up to 255 characters. Passing a longer string will result in an error. If you don't pass a request ID for a call, finAPI will generate a random ID internally. The request ID is always returned back in the response of a service, as a header with name "X-Request-Id". We highly recommend to always pass a (preferably unique) request ID, and include it into your client application logs whenever you make a request or receive a response (especially in the case of an error response). finAPI is also logging request IDs on its end. Having a request ID can help the finAPI support team to work more efficiently and solve tickets faster. Overriding HTTP methods Some HTTP clients do not support the HTTP methods PATCH or DELETE. If you are using such a client in your application, you can use a POST request instead with a special HTTP header indicating the originally intended HTTP method. The header's name is X-HTTP-Method-Override. Set its value to either PATCH or DELETE. POST Requests having this header set will be treated either as PATCH or DELETE by the finAPI servers. Example: X-HTTP-Method-Override: PATCH POST /api/v2/label/51 {"name": "changed label"} will be interpreted by finAPI as: PATCH /api/v2/label/51 {"name": "changed label"} User metadata With the migration to PSD2 APIs, a new term called "User metadata" (also known as "PSU metadata") has been introduced to the API. This user metadata aims to inform the banking API if there was a real end-user behind an HTTP request or if the request was triggered by a system (e.g. by an automatic batch update). In the latter case, the bank may apply some restrictions such as limiting the number of HTTP requests for a single consent. Also, some operations may be forbidden entirely by the banking API. For example, some banks do not allow issuing a new consent without the end-user being involved. Therefore, it is certainly necessary and obligatory for the customer to provide the PSU metadata for such operations. As finAPI does not have direct interaction with the end-user, it is the client application's responsibility to provide all the necessary information about the end-user. This must be done by sending additional headers with every request triggered on behalf of the end-user. At the moment, the following headers are supported by the API: • "PSU-IP-Address" - the IP address of the user's device. It has to be an IPv4 address, as some banks cannot work with IPv6 addresses. If a non-IPv4 address is passed, we will replace the value with our own IPv4 address as a fallback. • "PSU-Device-OS" - the user's device and/or operating system identification. • "PSU-User-Agent" - the user's web browser or other client device identification. FAQ Is there a finAPI SDK? Currently we do not offer a native SDK, but there is the option to generate an SDK for almost any target language via OpenAPI. Use the 'Download SDK' button on this page for SDK generation. How can I enable finAPI's automatic batch update? Currently there is no way to set up the batch update via the API. Please contact [email protected] for this. Why do I need to keep authorizing when calling services on this page? This page is a "one-page-app". Reloading the page resets the OAuth authorization context. There is generally no need to reload the page, so just don't do it and your authorization will persist.

Go to Download

# Authentication Requests made to our APIs must be authenticated, there are two ways to do this: 1. Authenticating using your API apiUsername and apiPassword - `Basic Auth` 2. Authenticating using an Auth Token - `Bearer Token` ## Method 1: Basic Auth Basic Authentication is a method for an HTTP user agent (e.g., a web browser) to provide a apiUsername and apiPassword when making a request. When employing Basic Authentication, users include an encoded string in the Authorization header of each request they make. The string is used by the request’s recipient to verify users’ identity and rights to access a resource. The Authorization header follows this format: > Authorization: Basic base64(apiUsername:apiPassword) So if your apiUsername and apiPassword are `onfon` and `!@pas123`, the combination is `onfon:!@pas123`, and when base64 encoded, this becomes `b25mb246IUBwYXMxMjM=`. So requests made by this user would be sent with the following header: > Authorization: Basic b25mb246IUBwYXMxMjM= | Description | | ---------------------------------------------------------------------------------------------- | | **apiUsername** `String` `Required` Your onfon account apiUsername, retrieved from portal | | **apiPassword** `String` `Required` Your onfon account apiPassword, retrieved from portal | ## Method 2: Bearer Tokens This authentication stategy allows you to authenticate using JSON Web Token ``JWT` that will expire after given duration. Each Access Token is a `JWT`, an encoded JSON object with three parts: the `header`, the `payload`, and the `signature`. The following is an example Access Token generated for Conversations > Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c ### Getting the token To generate the token, make a `POST` request to `/v1/authorization` endpoint with your `apiUsername` and `apiPassword` This request should be made from your server and not on the client side such as browser or mobile environment. You will receive a JSON similar to below: `{ "token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c", "validDurationSeconds": 3600}` You can use the token received to make API calls. The token will be valid for value of `validDurationSeconds`, before which you should generate a new token. #### Request Body ``` { "apiUsername": "root", "apiPassword": "hakty11" } ``` #### Response Body ``` { "token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c", "validDurationSeconds": 3600 } ``` #### Example Curl ``` curl --location --request POST 'https://apis.onfonmedia.co.ke/v1/authorization' \ --data-raw '{ "apiUsername": "correctapiUsername", "apiPassword": "correctapiPassword" } ``` #### Making an API call You will be required to pass the token in `Authorization` header prefixed by `Bearer` when calling other endpoints. Example `Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c`

Go to Download

A Laravel package designed to simplify the creation of structured and formatted API responses (JSON, XML) with custom status codes, messages, and data. XML support is currently under construction.

Go to Download

KML Library - libKML maps KML/KMZ data into proper objects that follows the KML specification. The purpose of the library is create KML file from code, parse KML files and convert to another formats maintaining the complete KML information.

Go to Download

Welcome to the CityPay API, a robust HTTP API payment solution designed for seamless server-to-server transactional processing. Our API facilitates a wide array of payment operations, catering to diverse business needs. Whether you're integrating Internet payments, handling Mail Order/Telephone Order (MOTO) transactions, managing Subscriptions with Recurring and Continuous Authority payments, or navigating the complexities of 3-D Secure authentication, our API is equipped to support your requirements. Additionally, we offer functionalities for Authorisation, Refunding, Pre-Authorisation, Cancellation/Voids, and Completion processing, alongside the capability for tokenised payments. ## Compliance and Security Overview Ensuring the security of payment transactions and compliance with industry standards is paramount. Our API is designed with stringent security measures and compliance protocols to safeguard sensitive information and meet the rigorous requirements of Visa, MasterCard, and the PCI Security Standards Council. ### Key Compliance and Security Measures * **TLS Encryption**: All data transmissions must utilise TLS version 1.2 or higher, employing [strong cryptography](#enabled-tls-ciphers). Our infrastructure strictly enforces this requirement to maintain the integrity and confidentiality of data in transit. We conduct regular scans and assessments of our TLS endpoints to identify and mitigate vulnerabilities. * **Data Storage Prohibitions**: Storing sensitive cardholder data (CHD), such as the card security code (CSC) or primary account number (PAN), is strictly prohibited. Our API is designed to minimize your exposure to sensitive data, thereby reducing your compliance burden. * **Data Masking**: For consumer protection and compliance, full card numbers must not be displayed on receipts or any customer-facing materials. Our API automatically masks PANs, displaying only the last four digits to facilitate safe receipt generation. * **Network Scans**: If your application is web-based, regular scans of your hosting environment are mandatory to identify and rectify potential vulnerabilities. This proactive measure is crucial for maintaining a secure and compliant online presence. * **PCI Compliance**: Adherence to PCI DSS standards is not optional; it's a requirement for operating securely and legally in the payments ecosystem. For detailed information on compliance requirements and resources, please visit the PCI Security Standards Council website [https://www.pcisecuritystandards.org/](https://www.pcisecuritystandards.org/). * **Request Validation**: Our API includes mechanisms to verify the legitimacy of each request, ensuring it pertains to a valid account and originates from a trusted source. We leverage remote IP address verification alongside sophisticated application firewall technologies to thwart a wide array of common security threats. ## Getting Started Before integrating with the CityPay API, ensure your application and development practices align with the outlined compliance and security measures. This preparatory step is crucial for a smooth integration process and the long-term success of your payment processing operations. For further details on API endpoints, request/response formats, and code examples, proceed to the subsequent sections of our documentation. Our aim is to provide you with all the necessary tools and information to integrate our payment processing capabilities seamlessly into your application. Thank you for choosing CityPay API. We look forward to supporting your payment processing needs with our secure, compliant, and versatile API solution.

Go to Download

Access Forem articles, users and other resources via API. For a real-world example of Forem in action, check out [DEV](https://www.dev.to). All endpoints that don't require authentication are CORS enabled. Dates and date times, unless otherwise specified, must be in the [RFC 3339](https://tools.ietf.org/html/rfc3339) format. # Authentication

Go to Download

MeCard is a data file similar to vCard but used by NTT DoCoMo in Japan in QR code format for use with Cellular Phones.

Go to Download

The **JsonShelter** class provides a simple, file-based JSON database solution. It allows for creating, reading, updating, and deleting records in structured JSON format. With an intuitive interface, it manages data storage in specified directories, ensuring seamless access to your data. Each record is uniquely identifiable, simplifying data manipulation and organization. Ideal for lightweight applications or prototyping, **JsonShelter** is easy to implement and maintain, making it a suitable choice for developers looking for a straightforward database solution.

Go to Download

# Code of Conduct Please don't abuse the API, and please report all feature requests and issues to https://support.atlassian.com/contact # Rate Limiting Each API token is limited to 1 request / second as measured on a 60 second rolling window. To get this limit increased, please contact us at https://support.atlassian.com/contact Error codes 420 or 429 indicate that you have exceeded the rate limit and the request has been rejected. # Basics ## HTTPS It's required ## URL Prefix In order to maintain version integrity into the future, the API is versioned. All calls currently begin with the following prefix: https://api.statuspage.io/v1/ ## RESTful Interface Wherever possible, the API seeks to implement repeatable patterns with logical, representative URLs and descriptive HTTP verbs. Below are some examples and conventions you will see throughout the documentation. * Collections are buckets: https://api.statuspage.io/v1/pages/asdf123/incidents.json * Elements have unique IDs: https://api.statuspage.io/v1/pages/asdf123/incidents/jklm456.json * GET will retrieve information about a collection/element * POST will create an element in a collection * PATCH will update a single element * PUT will replace a single element in a collection (rarely used) * DELETE will destroy a single element ## Sending Data Information can be sent in the body as form urlencoded or JSON, but make sure the Content-Type header matches the body structure or the server gremlins will be angry. All examples are provided in JSON format, however they can easily be converted to form encoding if required. Some examples of how to convert things are below: // JSON { "incident": { "name": "test incident", "components": ["8kbf7d35c070", "vtnh60py4yd7"] } } // Form Encoded (using curl as an example): curl -X POST https://api.statuspage.io/v1/example \ -d "incident[name]=test incident" \ -d "incident[components][]=8kbf7d35c070" \ -d "incident[components][]=vtnh60py4yd7" # Authentication

Go to Download

RESTful API for Account Information Services (AIS) and Payment Initiation Services (PIS) The following pages give you some general information on how to use our APIs. The actual API services documentation then follows further below. You can use the menu to jump between API sections. This page has a built-in HTTP(S) client, so you can test the services directly from within this page, by filling in the request parameters and/or body in the respective services, and then hitting the TRY button. Note that you need to be authorized to make a successful API call. To authorize, refer to the 'Authorization' section of the API, or just use the OAUTH button that can be found near the TRY button. General information Error Responses When an API call returns with an error, then in general it has the structure shown in the following example: { "errors": [ { "message": "Interface 'FINTS_SERVER' is not supported for this operation.", "code": "BAD_REQUEST", "type": "TECHNICAL" } ], "date": "2020-11-19 16:54:06.854", "requestId": "selfgen-312042e7-df55-47e4-bffd-956a68ef37b5", "endpoint": "POST /api/v1/bankConnections/import", "authContext": "1/21", "bank": "DEMO0002 - finAPI Test Redirect Bank" } If an API call requires an additional authentication by the user, HTTP code 510 is returned and the error response contains the additional "multiStepAuthentication" object, see the following example: { "errors": [ { "message": "Es ist eine zusätzliche Authentifizierung erforderlich. Bitte geben Sie folgenden Code an: 123456", "code": "ADDITIONAL_AUTHENTICATION_REQUIRED", "type": "BUSINESS", "multiStepAuthentication": { "hash": "678b13f4be9ed7d981a840af8131223a", "status": "CHALLENGE_RESPONSE_REQUIRED", "challengeMessage": "Es ist eine zusätzliche Authentifizierung erforderlich. Bitte geben Sie folgenden Code an: 123456", "answerFieldLabel": "TAN", "redirectUrl": null, "redirectContext": null, "redirectContextField": null, "twoStepProcedures": null, "photoTanMimeType": null, "photoTanData": null, "opticalData": null } } ], "date": "2019-11-29 09:51:55.931", "requestId": "selfgen-45059c99-1b14-4df7-9bd3-9d5f126df294", "endpoint": "POST /api/v1/bankConnections/import", "authContext": "1/18", "bank": "DEMO0001 - finAPI Test Bank" } An exception to this error format are API authentication errors, where the following structure is returned: { "error": "invalid_token", "error_description": "Invalid access token: cccbce46-xxxx-xxxx-xxxx-xxxxxxxxxx" } Paging API services that may potentially return a lot of data implement paging. They return a limited number of entries within a "page". Further entries must be fetched with subsequent calls. Any API service that implements paging provides the following input parameters: • "page": the number of the page to be retrieved (starting with 1). • "perPage": the number of entries within a page. The default and maximum value is stated in the documentation of the respective services. A paged response contains an additional "paging" object with the following structure: { ... , "paging": { "page": 1, "perPage": 20, "pageCount": 234, "totalCount": 4662 } } Internationalization The finAPI services support internationalization which means you can define the language you prefer for API service responses. The following languages are available: German, English, Czech, Slovak. The preferred language can be defined by providing the official HTTP Accept-Language header. finAPI reacts on the official iso language codes "de", "en", "cs" and "sk" for the named languages. Additional subtags supported by the Accept-Language header may be provided, e.g. "en-US", but are ignored. If no Accept-Language header is given, German is used as the default language. Exceptions: • Bank login hints and login fields are only available in the language of the bank and not being translated. • Direct messages from the bank systems typically returned as BUSINESS errors will not be translated. • BUSINESS errors created by finAPI directly are available in German and English. • TECHNICAL errors messages meant for developers are mostly in English, but also may be translated. Request IDs With any API call, you can pass a request ID via a header with name "X-Request-Id". The request ID can be an arbitrary string with up to 255 characters. Passing a longer string will result in an error. If you don't pass a request ID for a call, finAPI will generate a random ID internally. The request ID is always returned back in the response of a service, as a header with name "X-Request-Id". We highly recommend to always pass a (preferably unique) request ID, and include it into your client application logs whenever you make a request or receive a response (especially in the case of an error response). finAPI is also logging request IDs on its end. Having a request ID can help the finAPI support team to work more efficiently and solve tickets faster. Overriding HTTP methods Some HTTP clients do not support the HTTP methods PATCH or DELETE. If you are using such a client in your application, you can use a POST request instead with a special HTTP header indicating the originally intended HTTP method. The header's name is X-HTTP-Method-Override. Set its value to either PATCH or DELETE. POST Requests having this header set will be treated either as PATCH or DELETE by the finAPI servers. Example: X-HTTP-Method-Override: PATCH POST /api/v1/label/51 {"name": "changed label"} will be interpreted by finAPI as: PATCH /api/v1/label/51 {"name": "changed label"} User metadata With the migration to PSD2 APIs, a new term called "User metadata" (also known as "PSU metadata") has been introduced to the API. This user metadata aims to inform the banking API if there was a real end-user behind an HTTP request or if the request was triggered by a system (e.g. by an automatic batch update). In the latter case, the bank may apply some restrictions such as limiting the number of HTTP requests for a single consent. Also, some operations may be forbidden entirely by the banking API. For example, some banks do not allow issuing a new consent without the end-user being involved. Therefore, it is certainly necessary and obligatory for the customer to provide the PSU metadata for such operations. As finAPI does not have direct interaction with the end-user, it is the client application's responsibility to provide all the necessary information about the end-user. This must be done by sending additional headers with every request triggered on behalf of the end-user. At the moment, the following headers are supported by the API: • "PSU-IP-Address" - the IP address of the user's device. • "PSU-Device-OS" - the user's device and/or operating system identification. • "PSU-User-Agent" - the user's web browser or other client device identification. FAQ Is there a finAPI SDK? Currently we do not offer a native SDK, but there is the option to generate a SDK for almost any target language via OpenAPI. Use the 'Download SDK' button on this page for SDK generation. How can I enable finAPI's automatic batch update? Currently there is no way to set up the batch update via the API. Please contact [email protected] for this. Why do I need to keep authorizing when calling services on this page? This page is a "one-page-app". Reloading the page resets the OAuth authorization context. There is generally no need to reload the page, so just don't do it and your authorization will persist.

Go to Download

Elastic APM bundle

Go to Download

PHP package for support python pickle format

Go to Download

##### API Overview - Accounts list and balance - Transaction overview (also for saving accounts) - Payments import - Statement list and download - FX rates ##### Authentication Before making a call to Premium API, you need to register your app at our _Developer portal_. This is where you get the **ClientID** that your application must send in the request as `X-IBM-Client-Id`. This is the key that grants your app access to the API. However, this may not be enough. Your application needs to use mTLS to call most operations here. Thus, you not only need _https_ but also a client certificate issued by us. The exception is two operations for FX rates that are accessible also without a client certificate. Each bank client/user can issue several certificates. Each certificate can permit different sets of operations (http methods) on different bank accounts. All this must be configured in Internet Banking first by each bank client/user (bank clients need to look under _Settings_ and do not forget to download the certificate at the last step). The certificate is downloaded in **PKCS#12** format as **\*.p12** file and protected by a password chosen by the bank client/user. Yes, your app needs the password as well to get use of the **\*p12** file for establishing mTLS connection to the bank. Client certificates issued in Internet Banking for bank clients/users have limited validity (e.g. **5 years**). However, **each year** certificates are automatically blocked and bank client/user must unblock them in Internet Banking. It is possible to do it in advance and prolong the time before the certificate is blocked. Your app should be prepared for these scenarios and it should communicate such cases to your user in advance to provide seamless service and high user-experience of your app. ##### Rate Limiting The number of requests in each API operation is limited to 10 per client per sliding second and 5000 per client per sliding day. The exception is the 'Download Statement' operation with the limits lowered to 5 per client per sliding second and 1500 per client per sliding day. This is because it transports potentially sizeable binary files. The consumer must be able to handle HTTP status 429 in case of exceeding these limits. Response headers `X-RateLimit-Limit-Second` and `X-RateLimit-Limit-Day` show the actual limits configured for the specific operation. Response headers `X-RateLimit-Remaining-Second` and `X-RateLimit-Remaining-Day` are returned to help prevent the limits from being exceeded. ##### Notes Be aware, that in certain error situations, API can return specific error structures along with 5xx status code, which is not explicitely defined below. ##### Quick Start Client Feel free to download a simple Java client that gives you quick access to our API.

Go to Download

Laravel API Response is a powerful and flexible package that provides a standardized way to structure API responses in Laravel applications. It offers a range of features to enhance your API development experience, including consistent response formatting, conditional responses, pagination support, rate limiting, and more.

Go to Download