Loading...
OpenAPI Directory | Velosimo Admin

# 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

# 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

Control and manages real Smartphone devices from browser and restful apis

Please see the complete Orbit API documentation at [https://api.orbit.love/](https://api.orbit.love/).

Welcome to the Daymet Single Pixel Extraction Tool API. You can use this API to download daily surface data within the Daymet database in a `csv` or `json` format for a single point. This API allows users to query a single geographic point by latitude and longitude in decimal degrees. A routine is executed that translates the (lon, lat) coordinates into projected Daymet (x,y) Lambert Conformal Coordinates. These coordinates are used to access the Daymet database of daily interpolated surface weather variables. Daily data from the nearest 1 km x 1 km Daymet grid cell are extracted from the database. If you would like to learn how to automate the download of multiple locations for the Daymet Single Pixel Extraction Tool, click [here](https://github.com/ornldaac/daymet-single-pixel-batch).

This is the full documentation of the [REST API](https://book.orthanc-server.com/users/rest.html) of Orthanc.

This reference is automatically generated from the source code of Orthanc. A [shorter cheat sheet](https://book.orthanc-server.com/users/rest-cheatsheet.html) is part of the Orthanc Book.

An earlier, manually crafted version from August 2019, is [still available](2019-08-orthanc-openapi.html), but is not up-to-date anymore ([source](https://groups.google.com/g/orthanc-users/c/NUiJTEICSl8/m/xKeqMrbqAAAJ)).

Search for information on companies using a website or company name and get access to Company Data, News, Blog Posts, Competitor Lists and much more.

AIaaS provides API access to our bot hosting platform and SDKs, allowing developers to easily integrate conversational interfaces into applications.

papinet API is a global initiative for the Forst and Paper supply chain.

Validate and generate passwords using open source tools

This is the API documentation for Patrowl Engines usage.

For general questions and support of the API, contact: webservices@paylocity.com # Overview Paylocity Web Services API is an externally facing RESTful Internet protocol. The Paylocity API uses HTTP verbs and a RESTful endpoint structure. OAuth 2.0 is used as the API Authorization framework. Request and response payloads are formatted as JSON. Paylocity supports v1 and v2 versions of its API endpoints. v1, while supported, won't be enhanced with additional functionality. For direct link to v1 documentation, please click [here](https://docs.paylocity.com/weblink/guides/Paylocity_Web_Services_API/v1/Paylocity_Web_Services_API.htm). For additional resources regarding v1/v2 differences and conversion path, please contact webservices@paylocity.com. ##### Setup Paylocity will provide the secure client credentials and set up the scope (type of requests and allowed company numbers). You will receive the unique client id, secret, and Paylocity public key for the data encryption. The secret will expire in 365 days. * Paylocity will send you an e-mail 10 days prior to the expiration date for the current secret. If not renewed, the second e-mail notification will be sent 5 days prior to secret's expiration. Each email will contain the code necessary to renew the client secret. * You can obtain the new secret by calling API endpoint using your current not yet expired credentials and the code that was sent with the notification email. For details on API endpoint, please see Client Credentials section. * Both the current secret value and the new secret value will be recognized during the transition period. After the current secret expires, you must use the new secret. * If you were unable to renew the secret via API endpoint, you can still contact Service and they will email you new secret via secure email. When validating the request, Paylocity API will honor the defaults and required fields set up for the company default New Hire Template as defined in Web Pay. # Authorization Paylocity Web Services API uses OAuth2.0 Authentication with JSON Message Format. All requests of the Paylocity Web Services API require a bearer token which can be obtained by authenticating the client with the Paylocity Web Services API via OAuth 2.0. The client must request a bearer token from the authorization endpoint: auth-server for production: https://api.paylocity.com/IdentityServer/connect/token auth-server for testing: https://apisandbox.paylocity.com/IdentityServer/connect/token Paylocity reserves the right to impose rate limits on the number of calls made to our APIs. Changes to API features/functionality may be made at anytime with or without prior notice. ##### Authorization Header The request is expected to be in the form of a basic authentication request, with the "Authorization" header containing the client-id and client-secret. This means the standard base-64 encoded user:password, prefixed with "Basic" as the value for the Authorization header, where user is the client-id and password is the client-secret. ##### Content-Type Header The "Content-Type" header is required to be "application/x-www-form-urlencoded". ##### Additional Values The request must post the following form encoded values within the request body: grant_type = client_credentials scope = WebLinkAPI ##### Responses Success will return HTTP 200 OK with JSON content: { "access_token": "xxx", "expires_in": 3600, "token_type": "Bearer" } # Encryption Paylocity uses a combination of RSA and AES cryptography. As part of the setup, each client is issued a public RSA key. Paylocity recommends the encryption of the incoming requests as additional protection of the sensitive data. Clients can opt-out of the encryption during the initial setup process. Opt-out will allow Paylocity to process unencrypted requests. The Paylocity Public Key has the following properties: * 2048 bit key size * PKCS1 key format * PEM encoding ##### Properties * key (base 64 encoded): The AES symmetric key encrypted with the Paylocity Public Key. It is the key used to encrypt the content. Paylocity will decrypt the AES key using RSA decryption and use it to decrypt the content. * iv (base 64 encoded): The AES IV (Initialization Vector) used when encrypting the content. * content (base 64 encoded): The AES encrypted request. The key and iv provided in the secureContent request are used by Paylocity for decryption of the content. We suggest using the following for the AES: * CBC cipher mode * PKCS7 padding * 128 bit block size * 256 bit key size ##### Encryption Flow * Generate the unencrypted JSON payload to POST/PUT * Encrypt this JSON payload using your _own key and IV_ (NOT with the Paylocity public key) * RSA encrypt the _key_ you used in step 2 with the Paylocity Public Key, then, base64 encode the result * Base64 encode the IV used to encrypt the JSON payload in step 2 * Put together a "securecontent" JSON object: { 'secureContent' : { 'key' : -- RSA-encrypted & base64 encoded key from step 3, 'iv' : -- base64 encoded iv from step 4 'content' -- content encrypted with your own key from step 2, base64 encoded } } ##### Sample Example { "secureContent": { "key": "eS3aw6H/qzHMJ00gSi6gQ3xa08DPMazk8BFY96Pd99ODA==", "iv": "NLyXMGq9svw0XO5aI9BzWw==", "content": "gAEOiQltO1w+LzGUoIK8FiYbU42hug94EasSl7N+Q1w=" } } ##### Sample C# Code using Newtonsoft.Json; using System; using System.IO; using System.Security.Cryptography; using System.Text; public class SecuredContent { [JsonProperty("key")] public string Key { get; set; } [JsonProperty("iv")] public string Iv { get; set; } [JsonProperty("content")] public string Content { get; set; } } public class EndUserSecureRequestExample { public string CreateSecuredRequest(FileInfo paylocityPublicKey, string unsecuredJsonRequest) { string publicKeyXml = File.ReadAllText(paylocityPublicKey.FullName, Encoding.UTF8); SecuredContent secureContent = this.CreateSecuredContent(publicKeyXml, unsecuredJsonRequest); string secureRequest = JsonConvert.SerializeObject(new { secureContent }); return secureRequest; } private SecuredContent CreateSecuredContent(string publicKeyXml, string request) { using (AesCryptoServiceProvider aesCsp = new AesCryptoServiceProvider()) { aesCsp.Mode = CipherMode.CBC; aesCsp.Padding = PaddingMode.PKCS7; aesCsp.BlockSize = 128; aesCsp.KeySize = 256; using (ICryptoTransform crt = aesCsp.CreateEncryptor(aesCsp.Key, aesCsp.IV)) { using (MemoryStream outputStream = new MemoryStream()) { using (CryptoStream encryptStream = new CryptoStream(outputStream, crt, CryptoStreamMode.Write)) { byte[] encodedRequest = Encoding.UTF8.GetBytes(request); encryptStream.Write(encodedRequest, 0, encodedRequest.Length); encryptStream.FlushFinalBlock(); byte[] encryptedRequest = outputStream.ToArray(); using (RSACryptoServiceProvider crp = new RSACryptoServiceProvider()) { crp.FromXmlstring(publicKeyXml); byte[] encryptedKey = crp.Encrypt(aesCsp.Key, false); return new SecuredContent() { Key = Convert.ToBase64string(encryptedKey), Iv = Convert.ToBase64string(aesCsp.IV), Content = Convert.ToBase64string(encryptedRequest) }; } } } } } } } ## Support Questions about using the Paylocity API? Please contact webservices@paylocity.com. # Deductions (v1) Deductions API provides endpoints to retrieve, add, update and delete deductions for a company's employees. For schema details, click here. # OnBoarding (v1) Onboarding API sends employee data into Paylocity Onboarding to help ensure an easy and accurate hiring process for subsequent completion into Web Pay. For schema details, click here.

GOV.UK Pay API (This version is no longer maintained. See openapi/publicapi_spec.json for latest API specification)

Open, scableable, transparent payroll API.

## Who is this for? This documentation is for developers creating their own integration with [Feedback's](https://www.pendo.io/product/feedback/) API. If you are doing a standard integration, there's a really easy [Javascript integration](https://help.receptive.io/hc/en-us/articles/209221969-How-to-integrate-Receptive-with-your-app) that you should know about before you go to the effort of building your own integration. ## Authentication API calls generally need to be authenticated. Generate an API Key at https://feedback.pendo.io/app/#/vendor/settings?section=integrate. This key should then be added to every request as a request header named 'auth-token' (preferred), or as a query parameter named 'auth-token'. ## Endpoint API endpoint is https://api.feedback.eu.pendo.io / https://api.feedback.us.pendo.io depending where your datacenter is located. ## Notes API endpoints are being added to this documentation as needed by customers. If you don't see an endpoint you need please contact support and if it exists we'll publish the docs here. The 'try it out' feature on this documentation page will probably be blocked by your browser because the Access-Control-Allow-Origin header has its value set by the Feedback server depending on your hostname. ## Generating client code This documentation is automatically generated from an OpenAPI spec available [here](http://apidoc.receptive.io/receptive.swagger.json). You can use Swagger to auto-generate API client code in many languages using the [Swagger Editor](http://editor.swagger.io/#/)

Hereafter is the documentation of the private API of [Pims: Pointages Intelligents pour le Monde du Spectacle](https://pims.io). This API is designed for 3rd-party softwares, editors and partners. Its main purpose is to give access the core data of a Pims customer (i.e. events, ticket counts and promotions). ## Authentication The API uses [basic access authentication](https://en.wikipedia.org/wiki/Basic_access_authentication), meaning you will need a username and password to get authorized. As each customer in Pims has its own domain (e.g. caramba.pims.io, gdp.pims.io...), each credentials will be valid for one domain/customer only. If you need dedicated credentials for one domain, please contact us. (In any case, we will need an explicit agreement from the customer before we create these credentials.)

To make your life easy, you can try all endpoints with the public credentials below, pointing to our [demo domain](https://demo.pims.io):
  • Base path: `https://demo.pims.io/api`
  • Username: `demo`
  • Password: `q83792db2GCvgYVdKpU3yG3R`
## Response format The API returns JSON and matches the [HAL specification](http://stateless.co/hal_specification.html). The `Content-Type` of each response will be `application/hal+json`, unless an error occurs. Please note that this documentation describes all responses “as if” they were plain JSON. The specificities of HAL are ignored on purpose, in order to remain compact and avoid repetition.
So when you read in the doc:
{
	"id": 123,
	"property1": "Lorem ipsum",
	"object": {
		"id": 456,
		"property2": 7.89
	}
}
... you'll get in the Real World®:
{
	"id": 123,
	"property2": "Lorem ipsum",
	"_embedded": {
		"object": {
			"id": 456,
			"property2": 7.89,
			"_links": {
				"self": {
					"href": "https://api.mydomain.com/other-item/456"
				}
			}
		}
	}
	"_links": {
		"self": {
			"href": "https://api.mydomain.com/item/123"
		}
	}
}
### Errors Errors return JSON too and tries to match the [Problem Details for HTTP APIs specification](https://tools.ietf.org/html/rfc7807). If it does not match this spec, that's either a bug or a compatibility issue. Please contact us to solve the problem. The `Content-Type` of errors will be `application/problem+json`. The content will match the following JSON: ```json { "type": "https://tools.ietf.org/html/rfc2616#section-10", "title": "Not Found", "status": 404, "detail": "Entity not found" } ``` ## Versioning The API is fully versionned, using an URL-versioning scheme: `https://demo.pims.io/api/v1/events`, `https://demo.pims.io/api/v2/events`,... The version part of the URL is optional, and will be completed with the last stable version if omitted. ## Pagination All responses corresponding to a collection of resources (e.g. `/venues` or `/series/:id/events`) are paginated. When so, you will only get the first 25 resources you asked for. If you need to get more resources in one call, you can use the `page_size` query parameter. E.g. `/venues?page_size=50` to get the 50 first venues. Also note that with HAL, the navigation in paginated responses is a piece of cake, as you can see below: ```json { "_links": { "self": { "href": "https://demo.pims.io/api/v1/events?page=1" }, "first": { "href": "https://demo.pims.io/api/v1/events" }, "last": { "href": "https://demo.pims.io/api/v1/events?page=14" }, "next": { "href": "https://demo.pims.io/api/v1/events?page=2" } }, "_embedded": { ... // data content goes here }, "page_count": 14, "page_size": 25, "total_items": 331, "page": 1 } ``` ## Filtering and sorting Every textual filter (e.g. `/events?label=U2`) and/or sort (e.g. `/events?sort=label`) performed with the API uses UTF8_UNICODE_CI collation, meaning it is: - Case insensitive: “Chloé” will be considered the same as “CHLOÉ”; - Diacritic insensitive: “Chloé” will be considered the same as “Chloe”. When performing a sort, it will always be *ascending* by default. To make it *descending*, just use a minus sign (`-`) in front of the parameter value (e.g. `/events?sort=-label`). ## I18n In responses, some labels can be translated (e.g. promotion types, event input types, etc.). These translatable labels are clearly indicated in the documentation below. By default, they will be displayed in English, but you can change this behaviour via the `Accept-Language` header. E.g., use `fr` as a value for French. ## PHP SDK We provide a simple yet convenient SDK for the PHP language, see [the Github page of the project](https://github.com/pimssas/pims-api-client-php). ## And now? Generaly, you will start by [fetching one or more events](#tag/Events). An event can be anything that occurs in one venue at one given date and time: a concert, a play, a match, a conference, etc. Additionnally, you can explore the [series](#tag/Series): a series is just a group of events (e.g. a tour or a festival). Once you retrieved the events you were interested in, you can look for the sales (ticket counts): - Get a quick overview with [`/events/:id/ticket-counts`](#operation/fetchAllTicketCounts) - Or get a full insight by calling these endpoints: 1. [`/events/:id/categories`](#operation/fetchAllEventsCategories) 2. [`/events/:id/channels`](#operation/fetchAllEventsChannels) 3. [`/events/:id/ticket-counts/detailed`](#operation/fetchAllDetailedTicketCounts) Eventually, you may also want to fetch the [promotions](#tag/Promotions). A promotion can be anything meant to leverage the sales: ads, marketing campaigns, buzz or news around the event, etc. A promotion can be linked to any combination of events and/or series.

Pinecone is a vector database. This is an unofficial, community-managed OpenAPI spec that (should) accurately model the Pinecone API. This project was developed independent of and is unaffiliated with Pinecone Systems. Users should switch to the official API spec, if and when Pinecone releases it.

The Plaid REST API. Please see https://plaid.com/docs/api for more details.

1601 api specs