Endpoints for system utilities. e.g.Health

APIs for sampling from and fine-tuning language models

The OpenALPR CarCheck API allows you to send images to the cloud for processing. The image will be analyzed for license plates and vehicle make/models. The results are returned in JSON format

This is an online openapi generator server. You can find out more at https://github.com/OpenAPITools/openapi-generator.

This is the API for OpenAPI space.

API for OpenAQ LCS

Latest Swagger specification for OpenData

Swagger for Account and Transaction API Specification

Swagger for Confirmation of Funds API Specification

Swagger for Event Notification API Specification - TPP Endpoints

Swagger for Payment Initiation API Specification

# Summary The **Swiss NextGen API** is based on the NextGenPSD2 *Framework Version 1.3.4* of the Berlin Group which offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGen Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The Swiss edtion refines the message formats specific to Switzerland and defines some matching examples. The possible Approaches are: * Redirect SCA Approach * *(Not recommended by obp.ch community) OAuth SCA Approach* * *(Not recommended by obp.ch community) Decoupled SCA Approach* * *(Not recommended by obp.ch community) Embedded SCA Approach without SCA method* * *(Not recommended by obp.ch community) Embedded SCA Approach with only one SCA method available* * *(Not recommended by obp.ch community) Embedded SCA Approach with Selection of a SCA method* Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional Therefore for a particular implementation of a compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the [Berlin Group API](https://www.berlin-group.org/nextgenpsd2-downloads).** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] "If in is "header" and the name field is "Accept", "Content-Type" or "Authorization", the parameter definition SHALL be ignored." The element "Accept" will not be defined in this file at any place. The elements "Content-Type" and "Authorization" are implicitly defined by the OpenApi tags "content" and "security". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a comlient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the API have to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space

Worldwide forward and reverse geocoding

The Socrata OpenDataNetwork (ODN) REST API exposes public data, often continuosly updated and enhanced, from many thousands of public government and non profit agencies. Much of this data originating from independent sources is fused together to create new, and often powerful, entity level data. The API, in addition to search and autosuggest capabilities for finding datasets, enables data based comparisons across geographical regions such as states, counties, metropolitan areas, cities and zip codes using highly vetted data providers such as US Census, BEA, HUD and others. Comparison data is preformatted for easy and efficient display on a chart, graph or interactive map. The API also exposes data organized by narrative style questions a human might ask. The questions can be rapidly found using an autosuggest style index, and then used to directly access all data needed to thoroughly and authoritatively answer the question. Retrieved data includes time series (temporally aligned), tabular, map heavy (includes spatial boundaries), and auto generated unstructured descriptive text. The ODN API does not duplicate API endpoints or services provided by public sector agencies, but rather, returns context relevant pre-populated REST URLs, when appropriate, so the caller can access data directly from the source. The [open source](http://github.com/socrata/odn-backend) API powers [OpenDataNetwork.com](http://OpenDataNetwork.com), an [open source](http://github.com/socrata/opendatanetwork.com) site; the site highlights myriad uses and provides API badges with contextually relevant API example REST endpoints and documentation pointers. Finally, we continuously add new dat sources which appear automatically in the API, so if your favorite data source is not available, check back soon. You can also join us [HERE](http://www.opendatanetwork.com/join-open-data-network) and receive updates or let us know which data sources you are most interested in. ## App Tokens Registering for and including a [Socrata application token](https://dev.socrata.com/docs/app-tokens.html) is _required_ for the ODN API. They can be passed either using the `app_token` parameter or the `X-App-Token` HTTP header.

A free & open API for FIGI discovery.

# Introduction [OpenFinTech.io](https://openfintech.io) is an open database that comprises of standardized primary data for FinTech industry.
It contains such information as geolocation data (countries, cities, regions), organizations, currencies (national, digital, virtual, crypto), banks, digital exchangers, payment providers (PSP), payment methods, etc.
It is created for communication of cross-integrated micro-services on "one language". This is achieved through standardization of entity identifiers that are used to exchange information among different services.
### UML UML Domain Model diagram you can find [here](https://api.openfintech.io/public_domain_model.png).
### Persistence Entities are updated not more than 1 time per day.
### Terms and Conditions This *OpenFinTech.io* is made available under the [Open Database License](http://opendatacommons.org/licenses/odbl/1.0/).
Any rights in individual contents of the database are licensed under the [Database Contents License](http://opendatacommons.org/licenses/dbcl/1.0/).
### Contacts For any questions, please email - info@openfintech.io
Or you can contact us at Gitter
Powered by [Paymaxi](https://www.paymaxi.com) # Get Started If you use [POSTMAN](https://www.getpostman.com) or similar program which can operate with swagger`s files - just [download](https://docs.openfintech.io) our spec and [import it](https://www.getpostman.com/docs/importing_swagger). Also you can try live [API demo](https://api.openfintech.io). ## Overview The OpenFinTech API is organized around [REST](https://en.wikipedia.org/wiki/Representational_state_transfer). Our API has predictable, resource-oriented URLs, and uses HTTP response codes to indicate API errors.
API is based on [JSON API](http://jsonapi.org) standard. JSON is returned by all API responses, including errors, although our API libraries convert responses to appropriate language-specific objects.
JSON API requires use of the JSON API media type (`application/vnd.api+json`) for exchanging data.
### Additional Request Headers #### ACCEPT HEADER Your requests should always include the header: ```curl Accept: application/vnd.api+json ``` ## Authentication To use OpenFinTech API no needed authorization. ## Versioning When we make changes to the API, we release new, dated versions. The current version is **2017-08-24**. Read our [API upgrades guide]() to see our API changelog and to learn more about backwards compatibility. ## Pagination OpenFinTech APIs to retrieve lists of banks, currencies and other resources - paginated to **100** items by default. The pagination information will be included in the list API response under the node name `meta` - contains information about listed objects [`total` - contains information about total count of listed objects, `pages` - count of pages], `links` - contain links to navigate between pages [`first` - link to first page, `prev` - link to previous page, `next` - link to next page, `last` - link to last page].
By default first page will be listed. For navigating through pages, use the page parameter (e.g. `page[number]`, `page[size]`).
The `page[size]` parameter can be used to set the number of records that you want to receive in the response.
The `page[number]` parameter can be used to set needed page number.
Example of response: ```json { "meta": { "total": 419, "pages": 42 }, "links": { "first": "/v1/{path}?page[number]=1&page[size]=10", "prev": "/v1/{path}?page[number]=39&page[size]=10", "next": "/v1/{path}?page[number]=41&page[size]=10", "last": "/v1/{path}?page[number]=42&page[size]=10" } ``` ### Sorting OpenFinTech\`s API supported query parameter to sort result collection [e.g. `?sort=code`]. Information about available parameters may be found in the endpoint description. Positive parameter [e.g. `?sort=code`] points to ascending sorting, negative [e.g. `?sort=-code`] - to descending sorting. Also, supported multiple sorting parameters [e.g. `?sort=code, -name, id`, etc.] ```curl https://api.openfintech.io/v1/countries?sort=name,-area ``` ### Filtering Filtering provided by unique query key `filter[*filtering_condition*]`. Information about available parameters may be found in the endpoint description. ```curl https://api.openfintech.io/v1/countries?filter[region]=europe ``` ## Images OpenFinTech provides two types of images: icons and logos. To get one of those types you should to use next url pattern: ``` curl https://api.openfintech.io/v1/{path}/{id}/{icon/logo} ``` Also, images can be resized by adding next parameters: `h={height}&w={width}`. For example, you want to get organization icon with width equals to 20 pixels: ``` curl https://api.openfintech.io/v1/organizations/{id}/icon?w=20&h=20 ``` If argument height or width is missing API returns original image with real sizes. ## Errors API uses conventional HTTP response codes to indicate the success or failure of an API request. In general, codes in the `2xx` range indicate success, codes in the `4xx` range indicate an error that failed given the information provided (e.g., a required parameter was omitted, etc.), and codes in the `5xx` range indicate an error with OpenFinTech's servers (these are rare). | Code | Description | |------|-------------| | 200 - OK | Everything worked as expected. | | 400 - Bad Request | The request was unacceptable, often due to missing a required parameter. | | 401 - Unauthorized | No valid API key provided. | | 402 - Request Failed | The parameters were valid but the request failed. | | 404 - Not Found | The requested resource doesn't exist. | | 409 - Conflict | The request conflicts with another request (perhaps due to using the same idempotent key). | | 429 - Too Many Requests | Too many requests hit the API too quickly. We recommend an exponential backoff of your requests. | | 500, 502, 503, 504 - Server Errors | Something went wrong on OpenFinTech's end. (These are rare.) |

A retrieval API for querying and filtering documents based on natural language queries and metadata

An OpenAPI description of the OpenLink Smart Data Bot REST API v1