The API for Sync for Expenses. Sync for Expenses is an API and a set of supporting tools. It has been built to enable corporate card and expense management platforms to provide high-quality integrations with multiple accounting platforms through a standardized API. [Read more...](https://docs.codat.io/sync-for-expenses/overview) [See our OpenAPI spec](https://github.com/codatio/oas)
Manage your Hosted CodeScan Service
OpenAPI for https://codesearch.debian.net/
This is an API for accessing all sorts of college football data. Please note that API keys should be supplied with "Bearer " prepended (e.g. "Bearer your_key"). API keys can be acquired from the CollegeFootballData.com website.
An API that provides names for colors based on their hex value
# Introduction
This API allows resellers to manage their resources in a simple, programmatic way using HTTP requests.
# Conventions
## Requests
The API supports different methods depending on the required action.
| Method | Description
| --- | ---
| GET | Retrieve resources in a collection or get a single resource.
Getters will never have any effect on the queried resources.
| POST | Create a new resource in a collection.
| PUT | Update an existing resource with its new representation.
| DELETE | Delete an existing resource.
## HTTP status codes
The API will reply with different HTTP statuscodes:
| StatusCode | Description
| --- | ---
| 200 OK | The requests was processed and you receive data as a result.
| 201 CREATED | The resource has been created. Either the Location header contains a link to the created resource, or links are being returned in the response body. The applied method will be indicated in the documentation.
| 202 ACCEPTED | The request has been validated and accepted. Because we need to do some background processing prior to returning the result, we cannot send back a useful representation.
| 204 NOCONTENT | The request has been processed, but no details can be returned.
| 400 BADREQUEST | Your request is malformed.
| 401 UNAUTHORIZED | You are not authorized. Follow the instructions in the Authorization documentation.
| 403 FORBIDDEN | Access to the resource or operation is not allowed.
| 404 NOTFOUND | The resource cannot be found.
| 410 GONE | The resource is permanently no longer available.
| 429 TOOMANYREQUESTS | The ratelimit has been exceeded. Please refer to the documentation on rate limiting for more details.
| 500 INTERNALSERVERERROR | An error occurred during the processing of the request. The error is unexpected and most likely due to a bug in the api.
In the event of a problem, the body of the response will usually contain an errorcode and errormessage.
In rare cases additional details about the error are reported.
Errorcodes 400-499 are considered to be client errors and indicate that there was an issue with the request.
We will not take any action besides monitoring.
Errorcodes 500-599 are considered to be server errors. The errors are monitored AND action will be taken to resolve the error.
## Formatting
Snake casing is applied on resources and query parameters.
The API is strictly returning JSON. No other formats are supported.
Datetimes are returned in ISO-8601 format.
## Pagination
Pagination is on by default on collections and is controlled by specifying *skip* and *take* parameters.
**Skip** indicates the number of results to skip and where to start the new take.
**Take** indicates the number of records to return. The returned number of items can be smaller than the requested take.
Paged results will have headers with useful information regarding the paging.
| Header | Description
| --- | ---
| X-Paging-Skipped | The number of results that have been skipped.
| X-Paging-Take | The number of items in the current take. The number might differ from the requested take. It represents the actual number of items returned in the response.
| X-Paging-TotalResults | The total number of results regardless of paging.
## Rate limiting
The number of requests per interval is limited. Detailed information on the rate limiting can be found in specific headers which will be sent on each request.
| Header | Description
| --- | ---
| X-RateLimit-Limit | The number of requests that can be made in a specific time interval.
| X-RateLimit-Usage | The number of requests already made in the current time interval.
| X-RateLimit-Remaining | The number of requests remaining until the reset.
| X-RateLimit-Reset | The number of seconds until the reset.
After the reset you are allowed to make as many requests as specified by the X-RateLimit-Limit header.
| Retry-After | The number of seconds you have to wait until you can make new requests.
This header is only present when the rate limit has been reached. It is identical to X-RateLimit-Reset.
When the ratelimit has been reached, all requests will return with a HTTP statuscode 429 and ReasonPhrase '*Too many requests, retry later.*'.
# Authentication
The Api uses HMAC authentication.
Hash-based message authentication code (HMAC) is a mechanism for calculating a message authentication code involving a hash function in combination with a secret key.
Both the integrity and the authenticity of the message are verified this way.
## Steps to generate the HMAC
1. Get your api key and secret from your controlpanel.
It is absolutely vital that the secret is never exposed. Once the secret is out, anyone would be able to generate hmacs to impersonate you.
In case your secret is compromised, you can generate a new api key and secret on your controlpanel.
2. Construct the input value for generating the hmac.
Concatenate:apikey, request method, path and querystring information, unix timestamp, nonce and content.
| | Description
| --- | ---
| apikey | The key that is linked to your user.
| request method | lowercased (eg: get, post, delete,...)
| path and querystring information | urlencoding of the lowercased relative path and querystring.
The path **MUST start with the api version (/v2)**.
The hexadecimal codes (percent encoding) MUST be uppercased.
| unix timestamp | the unix timestamp in **seconds**.
| nonce | a unique string for each request. It should be a random string, not related to the request. The nonce (in combination with the unix timestamp) protects you from replay attacks in case anyone was able to intercept a request.
| content | When the request body is not empty, this should be the Base64 encoded Md5 hash of the request body.
An empty body should not be encoded.
3. Hash the concatenated string using your api secret and the SHA-256 algorithm.
4. Base64 encode the result of the hash function. This is the hmac signature you will need to send an authorized request.
## Sending an authorized request
An authorized request can be made by sending the generated HMAC in the authorization header.
A correct authorizationheader uses the hmac authorization scheme and a correctly formatted authorization parameter.
Create the authorization parameter by concatenating:
* apikey
* colon ':'
* generated HMAC signature (see above)
* colon ':'
* nonce (the one used to generate the signature)
* colon ':'
* unix timestamp (the one used to generate the signature)
A sample (illustrated):
* The first line is the string you create to feed to the hashing algorithm.
* The second line is the authorization header that should be sent in the request.
## IP whitelisting
Access is by default restricted for all IP addresses. You need to explicitly whitelist an IP or an IP range in your controlpanel.
# Versioning
Because of breaking contract changes compared to v1, we released v2 of the API.
V1 will still be available, but you are strongly encouraged to migrate to the latest version.
New features will only be available on v2.
# Policy
### Fair use policy
Please respect the rate limits and do not use the api for any purposes of abuse.
All requests are being monitored and logged.
Intentional abuse might result in api key revocation.
# Errors
The API attempts to return appropriate HTTP status codes for every request.
When the status code indicates failure, the API will also provide an error message in most cases.
An error message contains a machine-parseable error code accompanied by a descriptive error text.
The text for an error message might change over time, but codes will stay the same.
[An overview of error codes can be found here](/v2/documentation/errorcodes).
# Change log
[An overview of new changes can be found here](/v2/documentation/changelog).
# Provisioning information
## Terminology
| Term | Definition |
| --- | --- |
| Servicepack | Defines a set of assets that belong together. An example is a hosting package which offers Linux hosting, a domain name, a couple of mailboxes and databases.
It also limits the size of individual assets within the same account. |
| Account | Represents an instance of the servicepack. It contains one or more assets. The number and size of assets is defined by the servicepack. |
| Asset | A manageable service. For example: a mysql database, a linux hosting, a mailbox,...
Some assets are created at the moment when the account is created. Other assets can be created afterwards.
## Common provisioning scenario
**Provisioning of an account with Linux hosting with one MySql database**
*Without a pre-existing account:*
1. Create a new account.
Perform a POST on the accounts route and provide the desired servicepack id and identifier (domain name).
2. Read the Location header from the response and perform a GET of the provided resource (a provisioning job).
3. When the response returns 200(OK), you should repeat the GET operation after a certain interval (Repeat this step).
When the response returns 201(Created), you should read the response body. This will contain links to the created resources.
This will usually hold only one link, but to be futureproof, this has been designed to return a collection.
4. The created resource will point to an account. You now know the account's Id and can continue with the provisioning of a MySql database on this account.
5. Perform a POST on the mysqldatabases route and provide the account id along with other requested information.
6. Read the Location header from the response and perform a GET of the provided resource (a provisioning job).
7. When the response returns 200(OK), you should repeat the GET operation after a certain interval (Repeat this step).
When the response returns 201(Created), you should read the response body. This will contain links to the created resources.
This will usually hold only one link, but to be futureproof, this has been designed to return a collection.
8. The created resource will point to a MySql database resource.
## SSL certificate requests
**Requesting an SSL certificate causes the purchase of a paying product.**
1. A certificate is created by adding an ssl certificate request.
2. Upon statuscode 201 you should query for certificate completion on the resource provided in the location response header.
3. The resource request can respond with different statuscodes:
- 200: the certificate request is ongoing.
Check the validations collection for validation values that are not auto_validated. Those should be set by you system.
Call verify domain validations once all validation values are in place. It might take some time for verification to take place. It is not necessary to call this method more than once. - 303: the certificate request is complete; there is no more certificate request resource available. Check the location header value to retrieve the representation of the resulting ssl certificate.
- 410: the certificate request does not exist anymore, there is no certificate created as a result of the request.
**Base API URL**: https://api.configcat.com If you prefer the swagger documentation, you can find it here: [Swagger UI](https://api.configcat.com/swagger). The purpose of this API is to access the ConfigCat platform programmatically. You can **Create**, **Read**, **Update** and **Delete** any entities like **Feature Flags, Configs, Environments** or **Products** within ConfigCat. The API is based on HTTP REST, uses resource-oriented URLs, status codes and supports JSON and JSON+HAL format. Do not use this API for accessing and evaluating feature flag values. Use the [SDKs instead](https://configcat.com/docs/sdk-reference/overview). # OpenAPI Specification The complete specification is publicly available here: [swagger.json](v1/swagger.json). You can use it to generate client libraries in various languages with [OpenAPI Generator](https://github.com/OpenAPITools/openapi-generator) or [Swagger Codegen](https://swagger.io/tools/swagger-codegen/) to interact with this API. # Authentication This API uses the [Basic HTTP Authentication Scheme](https://en.wikipedia.org/wiki/Basic_access_authentication). # Throttling and rate limits All the rate limited API calls are returning information about the current rate limit period in the following HTTP headers: | Header | Description | | :- | :- | | X-Rate-Limit-Remaining | The maximum number of requests remaining in the current rate limit period. | | X-Rate-Limit-Reset | The time when the current rate limit period resets. | When the rate limit is exceeded by a request, the API returns with a `HTTP 429 - Too many requests` status along with a `Retry-After` HTTP header.
This is an API definition for CyberArk Conjur Open Source. You can find out more at [Conjur.org](https://www.conjur.org/).
Learn more about home mortgage data, download the data yourself, or build new tools using our API.
# Overview The ContentGroove Developer API enables you to add the power of ContentGroove's video AI to your own applications and workflows. Webhooks are a way for ContentGroove to send video information to your application, to update your system and/or trigger other business processes. You can use Webhooks and the Developer API separately or together. # Getting Started with Webhooks - Sign up for an account at [app.contentgroove.com](https://app.contentgroove.com) - Read "Using Webhooks" on the [API Reference page](https://developers.contentgroove.com/api_reference) - Visit the [Webhooks page](https://app.contentgroove.com/webhook_subscriptions) and create a new webhook # Using Webhooks Webhooks, also known as callbacks, are a way for ContentGroove to notify your application as soon as possible after an event has occurred in ContentGroove. For example after a media completes processing, ContentGroove can use a webhook to notify your application with information about the video: Suggested clips, transcription, and so on. You can use the information sent to update your system and/or use the webhook to trigger other business processes. The webhook request is sent as an HTTP POST containing a payload of JSON-formatted data. For the details of the payload format see the "CALLBACKS" sections below. When your application receives the webhook request, it must respond with a 200 HTTP status code (success). If a 200 HTTP status code is not returned, ContentGroove will assume that the webhook was not delivered and will retry a limited number of times, using an exponential backoff algorithm. ContentGroove makes a best effort to attempt to send the webhook at least once. Applications receiving webhooks must tolerate the possibility of a single webhook payload being sent more than once (idempotent behavior). Applications receiving webhooks should tolerate the possibility that a webhook could not be delivered (for example your application was down when delivery was attempted). # Getting Started with the Developer API - Sign up for an account at [app.contentgroove.com](https://app.contentgroove.com) - Visit the [API Keys page](https://app.contentgroove.com/api_keys) - Create a new API Key then copy and save the value. > ⚠️ **IMPORTANT**: This API Key is intended only for use on the server side. Be sure never to use a server-side API Key in client-side (web, mobile, or otherwise) code. ⚠️ - View all available endpoints, and try the API, on our [API Reference page](https://developers.contentgroove.com/api_reference) # Using the Developer API - Create a new media (video or audio) in ContentGroove - If the video or audio is available from a URL, you can create a media by providing the `source_url` parameter. ContentGroove will fetch the video or audio from the URL if possible. - Or, you can create a media from a video or audio file which you upload directly to ContentGroove (see File Uploading section below). - After the new media is created, at first it will be in a "processing" state. Depending on the size and duration of the video or audio file, it will take some time for processing to complete. - You can use ContentGroove Webhooks to be notified immediately when processing has completed. (Details coming soon.) - You can also use the API to read the state of the media, to determine if the media has completed processing yet. - After the media has completed processing, you can access all of these details about the media: - The media name and description - The transcription of spoken words - Topics and keywords which were discussed in the transcription - Suggested video clips are automatically created - In addition to the automatically created video clips, you can create more video clips from the media # Response Codes The following is a comprehensive list of the status codes you may receive while using the ContentGroove API: - 200 "Ok" - The request was valid - 400 "Bad Request - This is returned when there was a problem parsing the JSON body of your request if you supplied the 'Content-Type': 'application/json' header, or if your request is missing the 'Content-Type' header altogether - 401 "Unauthorized" - This is returned when you are attempting to perform an action on a resource that you are not authorized to do - 402 "Payment Required" - This is returned when you are attempting to perform an action that would push your account above a usage limit. You can view your usage at: https://app.contentgroove.com/quota_usage - 404 "Not Found" - This is returned when the resource you are trying to view does not exist - 429 "Too Many Requests" - This is returned when you have performed too many requests within a given period of time - 500 "Internal Server Error" - This is returned when your request was valid but there was a problem on our end # File Uploading - Step 1: Make a GET request to the direct uploads URL endpoint (/api/v1/direct_uploads) to receive an upload URL to upload the file to and an upload id. - Step 2: Make a PUT request with the file as the body to the upload URL received in step 1. The response will have a 200 status with no body if the upload is successful. ``` curl -T /path/to/file upload_url ``` - Step 3: After uploading the file to the upload URL, make a POST request to the create medias endpoint (/api/v1/medias), with the upload id and optionally a name and description for the new media. > At this time, file uploads are limited to 5gb per file. # Allowed media types Video: - Supported: Most common video formats and codecs are supported. - Recommended: mp4 Audio: - Supported: aac, mp3, flac, ogg, wav, and wma - Recommended: aac # Authentication You can use the API Key to authenticate your API requests using any of these methods. (Replace abc123 with your actual API Key.) - Request header `Authorization: Bearer abc123` - Request header `X-API-KEY: abc123` - Query parameter `api_key=abc123` > ⚠️ **IMPORTANT**: This API Key is intended only for use on the server side. Be sure never to use a server-side API Key in client-side (web, mobile, or otherwise) code. ⚠️ # Link to openapi.json spec - https://api.contentgroove.com/api-docs/v1/openapi.json
This OpenAPI describes the API exposed by the contract.fit backend. ## Security ### Authentication All endpoints are protected: you need to make authenticated calls. There are 3 authentication mechanisms: - HTTP Basic (Username + Password) - JWT Token - API-Key By default you should have an account allowing you to bootstrap your tenant and create users and roles, using Basic Auth or after creating a Token - see */auth* endpoints. If you are missing credentials or permissions, please [contact us](https://contract.fit/contact-us). ### Authorization The security system is RBAC based: users must be granted scoped roles, allowing them to access resources. Each role grants a defined set of permissions, which can be restricted to a given inbox or document - see */roles* endpoints. ## Upload and Processing Below is a short description of common use cases of the API. ### Simple Upload The easiest and simplest way to get started is to use POST /documents : it will make a synchronous upload of your file and wait for the result. This is a simplified version of POST /documents/{inbox_id} with less arguments and settings; it may not be suitable for real workload as it offers less capabilities. ### Upload to Inbox The favored endpoint to upload files is POST /documents/{inbox_id}: it is also highly recommended to make async call using sync=false. **Sync / Async** For convenience uploads can be synchronous: it will make the request blocks until the document is processed. It is however discouraged to rely on sync requests, as our service is designed to process documents asynchronously. You might run into timeouts and unprocessed document depending on factors such as server load and number of pending documents. Asynchronous calls will only schedule the processing and directly return the document ID without waiting: the document will be processed as soon as possible. You can then wait for the processed result using GET */documents/{document_id}*. ### Reprocessing You can reprocess a document using POST */documents/{document_id}/reprocess* : it will schedule an async processing of the document (note: it is not possible to make a sync reprocessing)
You can use the CORE API to access the resources harvested and enriched by CORE. If you encounter any problems with the API, please report them to us.
Overview
The API is organised by resource type. The resources are articles, journals and repositories and are represented using JSON data format. Furthermore, each resource has a list of methods. The API also provides two global methods for accessing all resources at once.
Response format
Response for each query contains two fields: status and data. In case of an error status, the data field is empty. The data field contains a single object in case the request is for a specific identifier (e.g. CORE ID, CORE repository ID, etc.), or contains a list of objects, for example for search queries. In case of batch requests, the response is an array of objects, each of which contains its own status and data fields. For search queries the response contains an additional field totalHits, which is the total number of items which match the search criteria.
Search query syntax
Complex search queries can be used in all of the API search methods. The query can be a simple string or it can be built using terms and operators described in Elasticsearch documentation. The usable field names are title, description, fullText, authors, publisher, repositories.id, repositories.name, doi, oai, identifiers (which is a list of article identifiers including OAI, URL, etc.), language.name and year. Some example queries:
title:psychology and language.name:English
repositories.id:86 AND year:2014
identifiers:"oai:aura.abdn.ac.uk:2164/3837" OR identifiers:"oai:aura.abdn.ac.uk:2164/3843"
doi:"10.1186/1471-2458-6-309"
Retrieving the latest Articles
You can retrieve the harvested items since specific dates using the following queries:
repositoryDocument.metadataUpdated:>2017-02-10
repositoryDocument.metadataUpdated:>2017-03-01 AND repositoryDocument.metadataUpdated:<2017-03-31
Sort order
For search queries, the results are ordered by relevance score. For batch requests, the results are retrieved in the order of the requests.
Parameters
The API methods allow different parameters to be passed. Additionally, there is an API key parameter which is common to all API methods. For all API methods the API key can be provided either as a query parameter or in the request header. If the API key is not provided, the API will return HTTP 401 error. You can register for an API key here.
API methods
*Corrently - from italian corrente, which is energy* # Introduction The Corrently ecosystem gets maintained by [STROMDAO GmbH](https://www.stromdao.de/) to support green energy services for prosumers, grid operators, regulators, integrators or any other party with an emerging need of consensus driven management. As the [energy product Corrently](https://www.corrently.de/) got first launched in Germany parts of this documentation provide simple translations for better understanding. [Released SKDs for Download](https://github.com/energychain/corrently-api/releases)
API to get Co-WIN vaccination certificate.
The PeerTube API is built on HTTP(S) and is RESTful. You can use your favorite
HTTP/REST library for your programming language to use PeerTube. The spec API is fully compatible with
[openapi-generator](https://github.com/OpenAPITools/openapi-generator/wiki/API-client-generator-HOWTO)
which generates a client SDK in the language of your choice - we generate some client SDKs automatically:
- [Python](https://framagit.org/framasoft/peertube/clients/python)
- [Go](https://framagit.org/framasoft/peertube/clients/go)
- [Kotlin](https://framagit.org/framasoft/peertube/clients/kotlin)
See the [REST API quick start](https://docs.joinpeertube.org/api/rest-getting-started) for a few
examples of using the PeerTube API.
# Authentication
When you sign up for an account on a PeerTube instance, you are given the possibility
to generate sessions on it, and authenticate there using an access token. Only __one
access token can currently be used at a time__.
## Roles
Accounts are given permissions based on their role. There are three roles on
PeerTube: Administrator, Moderator, and User. See the [roles guide](https://docs.joinpeertube.org/admin/managing-users#roles) for a detail of their permissions.
# Errors
The API uses standard HTTP status codes to indicate the success or failure
of the API call, completed by a [RFC7807-compliant](https://tools.ietf.org/html/rfc7807) response body.
```
HTTP 1.1 404 Not Found
Content-Type: application/problem+json; charset=utf-8
{
"detail": "Video not found",
"docs": "https://docs.joinpeertube.org/api/rest-reference.html#operation/getVideo",
"status": 404,
"title": "Not Found",
"type": "about:blank"
}
```
We provide error `type` values for [a growing number of cases](https://github.com/Chocobozzz/PeerTube/blob/develop/shared/models/server/server-error-code.enum.ts),
but it is still optional. Types are used to disambiguate errors that bear the same status code
and are non-obvious:
```
HTTP 1.1 403 Forbidden
Content-Type: application/problem+json; charset=utf-8
{
"detail": "Cannot get this video regarding follow constraints",
"docs": "https://docs.joinpeertube.org/api/rest-reference.html#operation/getVideo",
"status": 403,
"title": "Forbidden",
"type": "https://docs.joinpeertube.org/api/rest-reference.html#section/Errors/does_not_respect_follow_constraints"
}
```
Here a 403 error could otherwise mean that the video is private or blocklisted.
### Validation errors
Each parameter is evaluated on its own against a set of rules before the route validator
proceeds with potential testing involving parameter combinations. Errors coming from validation
errors appear earlier and benefit from a more detailed error description:
```
HTTP 1.1 400 Bad Request
Content-Type: application/problem+json; charset=utf-8
{
"detail": "Incorrect request parameters: id",
"docs": "https://docs.joinpeertube.org/api/rest-reference.html#operation/getVideo",
"instance": "/api/v1/videos/9c9de5e8-0a1e-484a-b099-e80766180",
"invalid-params": {
"id": {
"location": "params",
"msg": "Invalid value",
"param": "id",
"value": "9c9de5e8-0a1e-484a-b099-e80766180"
}
},
"status": 400,
"title": "Bad Request",
"type": "about:blank"
}
```
Where `id` is the name of the field concerned by the error, within the route definition.
`invalid-params.
An API collection for Covid 19 by Crediwatch
What's in this version: 1. Compare two screenshots for layout differences 2. Compare a full screenshot test of browsers to a single baseline browser for layout differences. 3. Compare a screenshot test version to another test version - good for regression tests. 4. Get links to the Comparison UI for visual representation of layout differences