This page contains the documentation on how to use Discourse through API calls. > Note: For any endpoints not listed you can follow the [reverse engineer the Discourse API](https://meta.discourse.org/t/-/20576) guide to figure out how to use an API endpoint. ### Request Content-Type The Content-Type for POST and PUT requests can be set to `application/x-www-form-urlencoded`, `multipart/form-data`, or `application/json`. ### Endpoint Names and Response Content-Type Most API endpoints provide the same content as their HTML counterparts. For example the URL `/categories` serves a list of categories, the `/categories.json` API provides the same information in JSON format. Instead of sending API requests to `/categories.json` you may also send them to `/categories` and add an `Accept: application/json` header to the request to get the JSON response. Sending requests with the `Accept` header is necessary if you want to use URLs for related endpoints returned by the API, such as pagination URLs. These URLs are returned without the `.json` prefix so you need to add the header in order to get the correct response format. ### Authentication Some endpoints do not require any authentication, pretty much anything else will require you to be authenticated. To become authenticated you will need to create an API Key from the admin panel. Once you have your API Key you can pass it in along with your API Username as an HTTP header like this: ``` curl -X GET "http://127.0.0.1:3000/admin/users/list/active.json" \ -H "Api-Key: 714552c6148e1617aeab526d0606184b94a80ec048fc09894ff1a72b740c5f19" \ -H "Api-Username: system" ``` and this is how POST requests will look: ``` curl -X POST "http://127.0.0.1:3000/categories" \ -H "Content-Type: multipart/form-data;" \ -H "Api-Key: 714552c6148e1617aeab526d0606184b94a80ec048fc09894ff1a72b740c5f19" \ -H "Api-Username: system" \ -F "name=89853c20-4409-e91a-a8ea-f6cdff96aaaa" \ -F "color=49d9e9" \ -F "text_color=f0fcfd" ``` ### Boolean values If an endpoint accepts a boolean be sure to specify it as a lowercase `true` or `false` value unless noted otherwise.

Domains-Index database powered API

This document is intended as a detailed reference for the precise behavior of the drchrono API. If this is your first time using the API, start with our tutorial. If you are upgrading from a previous version, take a look at the changelog section. # Authorization ## Initial authorization There are three main steps in the OAuth 2.0 authentication workflow: 1. Redirect the provider to the authorization page. 2. The provider authorizes your application and is redirected back to your web application. 3. Your application exchanges the `authorization_code` that came with the redirect for an `access_token` and `refresh_token`. ### Step 1: Redirect to drchrono The first step is redirecting your user to drchrono, typically with a button labeled "Connect to drchrono" or "Login with drchrono". This is just a link that takes your user to the following URL: https://drchrono.com/o/authorize/?redirect_uri=REDIRECT_URI_ENCODED&response_type=code&client_id=CLIENT_ID_ENCODED&scope=SCOPES_ENCODED - `REDIRECT_URI_ENCODED` is the URL-encoded version of the redirect URI (as registered for your application and used in later steps). - `CLIENT_ID_ENCODED` is the URL-encoded version of your application's client ID. - `SCOPES_ENCODED` is a URL-encoded version of a space-separated list of scopes, which can be found in each endpoint or omitted to default to all scopes. The `scope` parameter consists of an optional, space-separated list of scopes your application is requesting. If omitted, all scopes will be requested. Scopes are of the form `BASE_SCOPE:[read|write]` where `BASE_SCOPE` is any of `user`, `calendar`, `patients`, `patients:summary`, `billing`, `clinical` and `labs`. You should request only the scopes you need. For instance, an application which sends "Happy Birthday!" emails to a doctor's patients on their birthdays would use the scope parameter `"patients:summary:read"`, while one that allows patients to schedule appointments online would need at least `"patients:summary:read patients:summary:write calendar:read calendar:write clinical:read clinical:write"`. ### Step 2: Provider authorization After logging in (if necessary), the provider will be presented with a screen with your application's name and the list of permissions you requested (via the `scope` parameter). When they click the "Authorize" button, they will be redirected to your redirect URI with a `code` query parameter appended, which contains an authorization code to be used in step 3. If they click the "Cancel" button, they will be redirected to your redirect URI with `error=access_denied` instead. Note: This authorization code expires extremely quickly, so you must perform step 3 immediately, ideally before rendering the resulting page for the end user. ### Step 3: Token exchange The `code` obtained from step 2 is usable exactly once to obtain an access token and refresh token. Here is an example token exchange in Python: import datetime, pytz, requests if 'error' in get_params: raise ValueError('Error authorizing application: %s' % get_params[error]) response = requests.post('https://drchrono.com/o/token/', data={ 'code': get_params['code'], 'grant_type': 'authorization_code', 'redirect_uri': 'http://mytestapp.com/redirect_uri', 'client_id': 'abcdefg12345', 'client_secret': 'abcdefg12345', }) response.raise_for_status() data = response.json() # Save these in your database associated with the user access_token = data['access_token'] refresh_token = data['refresh_token'] expires_timestamp = datetime.datetime.now(pytz.utc) + datetime.timedelta(seconds=data['expires_in']) You now have all you need to make API requests authenticated as that provider. When using this access token, you'll only be able to access the data that the user has access to and that you have been granted permissions for. ## Refreshing an access token Access tokens only last 48 hours (given in seconds in the `'expires_in'` key in the token exchange step above), so they occasionally need to be refreshed. It would be inconvenient to ask the user to re-authorize every time, so instead you can use the refresh token like the original authorization to obtain a new access token. Replace the `code` parameter with `refresh_token`, change the value `grant_type` from `authorization_code` to `refresh_token`, and omit the `redirect_uri` parameter. Example in Python: ... response = requests.post('https://drchrono.com/o/token/', data={ 'refresh_token': get_refresh_token(), 'grant_type': 'refresh_token', 'client_id': 'abcdefg12345', 'client_secret': 'abcdefg12345', }) ... # Webhooks In order to use drchrono API webhooks, you first need to have an API application on file (even if it is in Test Model). Each API webhook is associated with one API application, go to here to set up both API applications and webhooks! Once you registered an API application, you will see webhook section in each saved API applications. Create a webhook and register some events there and save all the changes, then you are good to go! ## Webhooks setup All fields under webhooks section are required. **Callback URL** Callback URl is used to receive all hooks when subscribed events are triggered. This should be an URL under your control. **Secret token** Secret token is used to verify webhooks, this is very important, please set something with high entropy. Also we will talk more about this later. **Events** Events is used to register events you want to receiver notification when they happen. Currently we support following events. Event name | Event description ---------- | ----------------- `APPOINTMENT_CREATE` | We will deliver a hook any time an appointment is created `APPOINTMENT_MODIFY` | We will deliver a hook any time an appointment is modified `PATIENT_CREATE` | We will deliver a hook any time a patient is created `PATIENT_MODIFY` | We will deliver a hook any time a patient is modified `PATIENT_PROBLEM_CREATE` | We will deliver a hook any time a patient problem is created `PATIENT_PROBLEM_MODIFY` | We will deliver a hook any time a patient problem is modified `PATIENT_ALLERGY_CREATE` | We will deliver a hook any time a patient allergy is created `PATIENT_ALLERGY_MODIFY` | We will deliver a hook any time a patient allergy is modified `PATIENT_MEDICATION_CREATE` | We will deliver a hook any time a patient medication is created `PATIENT_MEDICATION_MODIFY` | We will deliver a hook any time a patient medication is modified `CLINICAL_NOTE_LOCK` | We will deliver a hook any time a clinical note is locked `CLINICAL_NOTE_UNLOCK` | We will deliver a hook any time a clinical note is unlocked `TASK_CREATE` | We will deliver a hook any time a task is created `TASK_MODIFY` | We will deliver a hook any time a task is modified and any time creation, modification and deletion of task notes, associated task item `TASK_DELETE` | We will deliver a hook any time a task is deleted ## Webhooks verification In order to make sure the callback URL in webhook is under your control, we added a verification step before we send any hooks out to you. Verification can be done by clicking "Verify webhook" button in webhooks setup page. After you click the button, we will send a `GET` request to the callback URL, along with a parameter called `msg`. Please use your webhook's secret token as hash key and SHA-256 as digest constructor, hash the `msg` value with HMAC algorithm. And we expect a `200` JSON response, in JSON response body, there should be a key called `secret_token` existing, and its value should be equal to the hashed `msg`. Otherwise, verification will fail. Here is an example webhook verification in Python: import hashlib, hmac def webhook_verify(request): secret_token = hmac.new(WEBHOOK_SECRET_TOKEN, request.GET['msg'], hashlib.sha256).hexdigest() return json_response({ 'secret_token': secret_token })

## Webhooks header and body **Header** Key | Value --- | ----- `X-drchrono-event` | Event that triggered this hook, could be any one event above or `PING` `X-drchrono-signature` | Secret token associated with this webhook `X-drchrono-delivery` | ID of this delivery **Body** Key | Value --- | ----- `receiver` | This will be an JSON representation of the webhook `object` | This will be an JSON representation of the object related to the triggered event, this would share same serializer as drchrono API ## Webhooks ping and deliveries Webhooks ping and deliveries will be sent as `POST` requests. **PING**: You can always ping your webhook to check things, by clicking the "Ping webhook" button in webhook setup page. And a hook with header `X-drchrono-event: PING` would be sent to the callback URL. **Deliveries**: You can check recent deliveries by clicking the "deliveries" link in webhook setup page. And you can resend a hook by clicking "redeliver" button after select a specific delivery. ## Webhooks delivery mechanism We will delivery a hook the moment a subscribed event is triggered. We will not record any response header or body you send back after you receive the hook. However we only consider the response status code. We will consider any `2xx` responses as successfully delivered. Any other responses, like `302` would be considered failing. And we will try to redeliver unsuccessfully delivered hooks 3 times, first redeliver happens at 1 hour after the initial event, second receliver happens 3 hours after the initial event, and the third redeliver happens 7 hours after the initial event. After these redeliveries, if the delivery is still unsuccessful, you have to redeliver it by hand. ## Webhooks security You may want to secure your webhooks to only consider requests send out from drchrono. And this is where secret_token is needed in request header. Try to set the secret_token to something with high entropy, a good example could be taking the output of ruby -rsecurerandom -e 'puts SecureRandom.hex(20)'. After this, you might want to verify all request headers you received on your server with this token. # iframe integration Some API apps provide additional functionality for interacting with patient data not offered by drchrono, and can benefit by being incorporated into drchrono's patient information page via iframe. We have created a simple API to make this possible. To make an existing API application accessible via an iframe on the patient page, you need to update either "Patient iframe" or "Clinical note iframe" section in API management page, to make the iframe to appear on (either the patient page or the clinical note page), with the URL that the iframe will use for each page, and the height it should have. The application will be reviewed before it is approved to ensure that it is functional and secure. ## Register a Doctor iframe applications will appear as choices on the left-hand menu of the patient page for doctors registered with your application. To register a doctor with your application, make a `POST` request to the `/api/iframe_integration` endpoint using the access token for the corresponding doctor. This endpoint does not expect any payload. To disable your iframe application for a doctor, make a `DELETE` request to the same endpoint. ## Populating the iframe There are two places where the iframe can be displayed, either within the patient detail page or the clinical note page, shown below respectively: When requesting approval for your iframe app, you must specify a URL for one or both of these pages which will serve as the base URL for your IFrame contents. When a doctor views your iframe, the source URL will have various query parameters appended to it, for example for the patient page the `src` parameter of the IFrame will be: ``` ?doctor_id=&patient_id=&practice_id=&iat=&jwt= ``` The `jwt` parameter is crucial if your application transfers any sort of PHI and does not implement its own login system. It encapsulates the other parameters in a [JSON web token (JWT)](http://jwt.io) and signs them using SHA-256 HMAC with your `client_secret` as the key. This verifies that the iframe is being loaded within one of drchrono's pages by an authorized user. In production, you should validate the JWT using an approved library (which are listed on the [official site](http://jwt.io)), and only use the parameters extracted from the JWT. Using Python and Django, this might look like: import jwt CLIENT_SECRET = MAX_TIME_DRIFT_SECONDS = 60 def validate_parameters(request): token = request.GET['jwt'] return jwt.decode(token, CLIENT_SECRET, algorithms=['HS256'], leeway=MAX_TIME_DRIFT_SECONDS) Modern browsers' same-origin policy means that data cannot be passed between your application and drchrono's page through the iframe. Therefore, interaction must happen through the API, using information provided in JWT. # Versions and deprecation ## Stability Policy Changes to this API version will be limited to adding endpoints, or adding fields to existing endpoints, or adding optional query parameters. Any new fields which are not read-only will be optional. ## Deprecation Policy The drchrono API is versioned. Versions can be in the following states: * **Active:** This is our latest and greatest version of the API. It is actively supported by our API team and is improved upon with new features, bug fixes and optimizations that do not break backwards compatibility. * **Deprecated:** A deprecated API version is considered second best--having been surpassed by our active API version. An API version remains in this state for one year, after which time it falls to the not supported state. A deprecated API version is passively supported; while it won't be removed until becoming unsupported, it may not receive new features but will likely be subject to security updates and performance improvements. * **Unsupported:** An API version in the not supported state may be deactivated at any time. An application using an unsupported API version should migrate to an active API version. ## Version Map | Version Name | Previous Name | Start Date | Deprecation Date | |--------------|---------------|------------|------------------| | v2 | v2015_08 | 08/2015 | TBA | | v3 | v2016_06 | 06/2016 | | | v4 | N/A | 09/2018 | | If you are looking for documentation for an older version - [V4(Hunt Valley)](/api-docs-old/v4/documentation) (old V4 documentation) - [V3(Sunnyvale)](/api-docs-old/v3/documentation) - [V2(Mountain View)](/api-docs-old/v2/documentation) # Changelog Here's changelog for different versions - [V4 Changelog](/api-docs-old/v4/changelog) - [V3 changelog](/api-docs-old/v3/changelog)

Dweet.io allows users to share data from mobile, tablets, and pcs, and them to other devices and accounts across social media platforms. Dweet.io provides an API to access the different functionality of the Dweet.io service. Users can make REST calls to read and create dweets, lock and unlock things, and perform other calls. The API returns JSON and JSONP.

edrv.io API Documentation

This is the documentation for the ElevenLabs API. You can use this API to use our service programmatically, this is done by using your xi-api-key.
You can view your xi-api-key using the 'Profile' tab on https://beta.elevenlabs.io. Our API is experimental so all endpoints are subject to change.

Download [OpenAPI 3.0 Specification](/OpenAPI-Enode-v1.4.0.json) Download [Postman Collection](/Postman-Enode-v1.4.0.json) The Enode API is designed to make smart charging applications easy to develop. We provide an abstraction layer that reduces the complexity when extracting vehicle data and sending commands to vehicles from a variety of manufacturers. The API has a RESTful architecture and utilizes OAuth2 authorization. We are always available to handle any issues or just answer your questions. Feel free to reach out on post@enode.io ## Registration for API access In order to use the API you will need a `client_id` and `client_secret`. Please contact us if you are interested in using our API in production, and we will provide these credentials. # Authorization Vehicle / hardware access via the Enode API is granted to your application by the User in a standard OAuth `Authorization Code` flow. > The authorization scheme documented here is the recommended approach for most situations. However, it is also possible to user other OAuth flows, non-confidential clients, and temporary users. Please feel free to contact us if you have any questions about your use-case or the integration of your existing infrastructure. ### Preparation: Configure your OAuth client Because Enode API implements the OAuth 2.0 spec completely and without modifications, you can avoid rolling your own OAuth client implementation and instead use a well-supported and battle-tested implementation. This is strongly recommended. Information on available OAuth clients for many languages is available [here](https://oauth.net/code/) To configure your chosen OAuth client, you will need these details: - Your `client_id` - Your `client_secret` - Authorization URL: `https://link.test.enode.io/oauth2/auth` - Token URL: `https://link.test.enode.io/oauth2/token` ```javascript // Node.js + openid-client example const enodeIssuer = await Issuer.discover('https://link.test.enode.io'); const client = new enodeIssuer.Client({ client_id: 'xyz', client_secret: 'shhhhh', redirect_uris: ['http://localhost:5000/callback'], response_types: ['code'], }); ``` ### Preparation: Obtain a client access token via OAuth Client Credentials Grant Your OAuth client will have a method for using the `OAuth 2.0 Client Credentials Grant` to obtain an access token. ```javascript // Node.js + openid-client example const clientAccessToken = await client.grant({grant_type: "client_credentials"}); ``` This access token belongs to your client and is used for administrative actions, such as the next step. This token should be cached by your server and reused until it expires, at which point your server should request a new one. ### Step 1. Generate an Enode Link session for your User and launch the OAuth flow When your User indicates that they want to connect their hardware to your app, your server must call [Link User](#operation/postUsersUseridLink) to generate an Enode Link session for your User. The User ID can be any string that uniquely identifies the User, but it is recommended that you use the primary key by which you identify the User within your application. Example Request: ``` POST /users/{userId}/link HTTP/1.1 Authorization: Bearer {access_token} { "forceLanguage": "nb-NO", "vendor": "Tesla", } ``` Example Response: ``` { "linkState": "ZjE2MzMxMGFiYmU4MzcxOTU1ZmRjMTU5NGU2ZmE4YTU3NjViMzIwY2YzNG", } ``` The returned linkState must be stored by your server, attached to the session of the authenticated user for which it was generated. Your OAuth client will provide a method to construct an authorization URL for your user. That method will require these details: - Redirect URI - The URI to which your user should be redirected when the Oauth flow completes - Scope - The OAuth scope(s) you wish to request access to (see list of valid values [here](#section/Authentication/AccessTokenBearer)) - State - The value of `linkState` from the request above To launch the OAuth flow, send your user to the authorization URL constructed by your OAuth client. This can be done in an embedded webview within a native iOS/Android app, or in the system's default browser. ```javascript // Node.js + openid-client + express example // Construct an OAuth authorization URL const authorizationUrl = client.authorizationUrl({ scope: "offline_access all", state: linkState }); // Redirect user to authorization URL res.redirect(authorizationUrl); ``` ### Step 2. User grants consent In the Link UI webapp the user will follow 3 steps: 1. Choose their hardware from a list of supported manufacturers (EVs and charging boxes). For certain EV makes it will be necessary to also select a charge box. 2. For each selection, the user will be presented with the login screen for that particular hardware. The user must successfully log in. 3. A summary of the requested scopes will be presented to the user. The user must choose whether to grant access to your application. ### Step 3. OAuth flow concludes with a callback When the user has completed their interactions, they will be redirected to the `Redirect URI` you provided in Step 1, with various metadata appended as query parameters. Your OAuth client will have a method to parse and validate that metadata, and fetch the granted access and refresh tokens. Among that metadata will be a `state` value - you must verify that it is equal to the `linkState` value persisted in Step 1, as [a countermeasure against CSRF attacks](https://tools.ietf.org/html/rfc6819#section-4.4.1.8). ```javascript // Node.js + openid-client + express example // Fetch linkState from user session const linkState = get(req, 'session.linkState'); // Parse relevant parameters from request URL const params = client.callbackParams(req); // Exchange authorization code for access and refresh tokens // In this example, openid-client does the linkState validation check for us const tokenSet = await client.oauthCallback('http://localhost:5000/callback', params, {state: linkState}) ``` With the access token in hand, you can now access resources on behalf of the user. # Errors And Problems ## OAuth Authorization Request When the User has completed the process of allowing/denying access in Enode Link, they will be redirected to your configured redirect URI. If something has gone wrong, query parameters `error` and `error_description` will be set as documented in [Section 4.1.2.1](https://tools.ietf.org/html/rfc6749#section-4.1.2.1) of the OAuth 2.0 spec: |error |error_description| |---------------------------|-----------------| |invalid_request |The request is missing a required parameter, includes an invalid parameter value, includes a parameter more than once, or is otherwise malformed.| |unauthorized_client |The client is not authorized to request an authorization code using this method.| |access_denied |The resource owner or authorization server denied the request.| |unsupported_response_type |The authorization server does not support obtaining an authorization code using this method.| |invalid_scope |The requested scope is invalid, unknown, or malformed.| |server_error |The authorization server encountered an unexpected condition that prevented it from fulfilling the request.| |temporarily_unavailable |The authorization server is currently unable to handle the request due to a temporary overloading or maintenance of the server| Example: ``` https://website.example/oauth_callback?state=e0a86fe5&error=access_denied&error_description=The+resource+owner+or+authorization+server+denied+the+request. ``` ## Errors when accessing a User's resources When using an `access_token` to access a User's resources, the following HTTP Status Codes in the 4XX range may be encountered: |HTTP Status Code |Explanation | |---------------------------|-----------------| |400 Bad Request |The request payload has failed schema validation / parsing |401 Unauthorized |Authentication details are missing or invalid |403 Forbidden |Authentication succeeded, but the authenticated user doesn't have access to the resource |404 Not Found |A non-existent resource is requested |429 Too Many Requests |Rate limiting by the vendor has prevented us from completing the request In all cases, an [RFC7807 Problem Details](https://tools.ietf.org/html/rfc7807) body is returned to aid in debugging. Example: ``` HTTP/1.1 400 Bad Request Content-Type: application/problem+json { "type": "https://docs.enode.io/problems/payload-validation-error", "title": "Payload validation failed", "detail": "\"authorizationRequest.scope\" is required", } ```

[](https://app.getpostman.com/run-collection/80638214aa04722c9203) or View Postman docs # Quickstart Visit [github](https://github.com/EmitKnowledge/Envoice) to view the quickstart tutorial.

# Webhooks Webhooks allow you to build or set up Envoice Apps which subscribe to invoice activities. When one of those events is triggered, we'll send a HTTP POST payload to the webhook's configured URL. Webhooks can be used to update an external invoice data storage. In order to use webhooks visit [this link](/account/settings#api-tab) and add upto 10 webhook urls that will return status `200` in order to signal that the webhook is working. All nonworking webhooks will be ignored after a certain period of time and several retry attempts. If after several attempts the webhook starts to work, we will send you all activities, both past and present, in chronological order. The payload of the webhook is in format: ``` { Signature: ""sha256 string"", Timestamp: ""YYYY-MM-DDTHH:mm:ss.FFFFFFFZ"", Activity: { Message: "string", Link: "share url", Type: int, InvoiceNumber: "string", InvoiceId: int, OrderNumber: "string", OrderId: int, Id: int, CreatedOn: "YYYY-MM-DDTHH:mm:ss.FFFFFFFZ" } } ```

The Ethiopian Movie Database

EVEMarketer Marketstat API is almost compatible with EVE-Central's Marketstat API.

An OpenAPI for EVE Online

Fetch the latest currency exchange rates via API. ExchangeRate-API is free and unlimited.

Api Documentation

The fire.com API allows you to deeply integrate Business Account features into your application or back-office systems. The API provides read access to your profile, accounts and transactions, event-driven notifications of activity on the account and payment initiation via batches. Each feature has its own HTTP endpoint and every endpoint has its own permission. The API exposes 3 main areas of functionality: financial functions, service information and service configuration. ## Financial Functions These functions provide access to your account details, transactions, payee accounts, payment initiation etc. ## Service Functions These provide information about the fees and limits applied to your account. ## Service configuration These provide information about your service configs - applications, webhooks, API tokens, etc.

IOTVAS API enables you to discover IoT/Connected devices in the network and provides detailed real-time risk analysis, including firmware vulnerability analysis without requiring the user to upload the firmware file. Please visit the [signup page](https://iotvas-api.firmalyzer.com/portal/signup) to create an API key. IoTVAS API can be easily integrated with vulnerability scanning and network port scanner tools. For example, we have also released the [IOTVAS NSE script](https://github.com/firmalyzer/iotvas-nmap) that turns the nmap port scanner to a IoT/connected device discovery and real-time risk assessment tool. For more infromation on IoTVAS and other solutions please visit [Firmalyzer web site](https://www.firmalyzer.com).

The Flat API allows you to easily extend the abilities of the [Flat Platform](https://flat.io), with a wide range of use cases including the following: * Creating and importing new music scores using MusicXML, MIDI, Guitar Pro (GP3, GP4, GP5, GPX, GP), PowerTab, TuxGuitar and MuseScore files * Browsing, updating, copying, exporting the user's scores (for example in MP3, WAV or MIDI) * Managing educational resources with Flat for Education: creating & updating the organization accounts, the classes, rosters and assignments. The Flat API is built on HTTP. Our API is RESTful It has predictable resource URLs. It returns HTTP response codes to indicate errors. It also accepts and returns JSON in the HTTP body. The [schema](/swagger.yaml) of this API follows the [OpenAPI Initiative (OAI) specification](https://www.openapis.org/), you can use and work with [compatible Swagger tools](http://swagger.io/open-source-integrations/). This API features Cross-Origin Resource Sharing (CORS) implemented in compliance with [W3C spec](https://www.w3.org/TR/cors/). You can use your favorite HTTP/REST library for your programming language to use Flat's API. This specification and reference is [available on Github](https://github.com/FlatIO/api-reference). Getting Started and learn more: * [API Overview and introduction](https://flat.io/developers/docs/api/) * [Authentication (Personal Access Tokens or OAuth2)](https://flat.io/developers/docs/api/authentication.html) * [SDKs](https://flat.io/developers/docs/api/sdks.html) * [Rate Limits](https://flat.io/developers/docs/api/rate-limits.html) * [Changelog](https://flat.io/developers/docs/api/changelog.html)

A subset of Flickr's API defined in Swagger format.

------ This API allows developers to integrate the Frankie Financial Compliance Utility into their applications. The API allows: - Checking name, address, date of birth against national databases - Validating Australian driver's licences, passports, medicare, visas and other Australian national ID documents - Validating Australian electricity bills - Validating NZ driver's licences - Validating Chinese bank cards and national ID card - Validating International passports and national ID documents - PEP, Sanctions, Watchlist and adverse media checking - Australian visa checks - Fraud list and fraud background checks - ID validation and selfie check comparisons. ------ Industry specific services - Comparing Australian electricity retailers for a better deal. ------ KYB specific services - Query organisation ownership - Perform KYC & AML checks on shareholders, beneficial owners and office bearers. - Query credit score and credit reports - International company searches - International company profiles ------ The full version of this documentation along with supplemental articles can be found here: - https://apidocs.frankiefinancial.com/ The traditional Swagger view of this documentation can be found here: - https://app.swaggerhub.com/apis-docs/FrankieFinancial/kycutility ------ Sandbox base URL is: - https://api.demo.frankiefinancial.io/compliance/v1.2 - We do have an old sandbox at https://sandbox.frankiefinancial.com/compliance/v1.2 but this has been retired. - All calls are the same as production, only with canned data. - Full Swagger definition, along with test data for playing in the sandbox can be obtained once initial commercial discussions have commenced. - Production and optional UAT access will be opened up only to those with a signed commercial contract. ------ Contact us at hello@frankiefinancial.com to speak with a sales rep about issuing a Customer ID and Sandbox api key.

With the Freesound APIv2 you can browse, search, and retrieve information about Freesound users, packs, and the sounds themselves of course. You can find similar sounds to a given target (based on content analysis) and retrieve automatically extracted features from audio files, as well as perform advanced queries combining content analysis features and other metadata (tags, etc...). With the Freesound APIv2, you can also upload, comment, rate and bookmark sounds!