Mock sample for your project: ConfigCat Public Management API
Integrate with "ConfigCat Public Management API" from configcat.com in no time with Mockoon's ready to use mock sample
ConfigCat Public Management API
Version: v1
Integrate third-party APIs faster by using "ConfigCat Public Management API" ready-to-use mock sample. Mocking this API will help you accelerate your development lifecycles and improves your integration tests' quality and reliability by accounting for random failures, slow response time, etc.
It also helps reduce your dependency on third-party APIs: no more accounts to create, API keys to provision, accesses to configure, unplanned downtime, etc.
Description
Base API URL: https://api.configcat.com
If you prefer the swagger documentation, you can find it here: Swagger UI.
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.
OpenAPI Specification
The complete specification is publicly available here: swagger.json.
You can use it to generate client libraries in various languages with OpenAPI Generator or
Swagger Codegen to interact with this API.
Authentication
This API uses the Basic HTTP Authentication Scheme.
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.
Other APIs in the same category
Appwrite
StackExchange
Spell Check Client
News Search Client
Snyk API
API vs CLI vs Snyk integration
The API detailed below has the ability to test a package for issues, as they are defined by Snyk. It is important to note that for many package managers, using this API will be less accurate than running the Snyk CLI as part of your build pipe, or just using it locally on your package. The reason for this is that more than one package version fit the requirements given in manifest files. Running the CLI locally tests the actual deployed code, and has an accurate snapshot of the dependency versions in use, while the API can only infer it, with inferior accuracy. It should be noted that the Snyk CLI has the ability to output machine-readable JSON output (with the --json flag to snyk test).
A third option, is to allow Snyk access to your development flow via the existing Snyk integrations. The advantage to this approach is having Snyk monitor every new pull request, and suggest fixes by opening new pull requests. This can be achieved either by integrating Snyk directly to your source code management (SCM) tool, or via a broker to allow greater security and auditability.
If those are not viable options, this API is your best choice.
API url
The base URL for all API endpoints is https://snyk.io/api/v1/
Authorization
To use this API, you must get your token from Snyk. It can be seen on https://snyk.io/account/ after you register with Snyk and login.
The token should be supplied in an Authorization header with the token, preceded by token:
Airbyte Configuration API
https://airbyte.io.
This API is a collection of HTTP RPC-style methods. While it is not a REST API, those familiar with REST should find the conventions of this API recognizable.
Here are some conventions that this API follows:
All endpoints are http POST methods.
All endpoints accept data via application/json request bodies. The API does not accept any data via query params.
The naming convention for endpoints is: localhost:8000/{VERSION}/{METHODFAMILY}/{METHODNAME} e.g. localhost:8000/v1/connections/create.
For all update methods, the whole object must be passed in, even the fields that did not change.
Change Management:
The major version of the API endpoint can be determined / specified in the URL localhost:8080/v1/connections/create
Minor version bumps will be invisible to the end user. The user cannot specify minor versions in requests.
All backwards incompatible changes will happen in major version bumps. We will not make backwards incompatible changes in minor version bumps. Examples of non-breaking changes (includes but not limited to...):
Adding fields to request or response bodies.
Adding new HTTP endpoints.
API Endpoints
Bitbucket API
OpenAPI Generator Online
