Mock sample for your project: CodeScan API
Integrate with "CodeScan API" from code-scan.com in no time with Mockoon's ready to use mock sample
CodeScan API
Version: 1.0.0
Integrate third-party APIs faster by using "CodeScan API" ready-to-use mock sample. Mocking this API will allow you to start working in no time. No more accounts to create, API keys to provision, accesses to configure, unplanned downtime, just work.
Improve your integration tests by mocking third-party APIs and cover more edge cases: slow response time, random failures, etc.
Description
Manage your Hosted CodeScan Service
Other APIs in the same category
OSDB REST API v1
openlinksw.com
An OpenAPI description of the OpenLink Smart Data Bot REST API v1
Extpose
Extpose — in‑store performance analytics and optimization tool for Chrome extensions. https://extpose.com
Api2Pdf - PDF Generation, Powered by AWS Lambda
Introduction
Api2Pdf is a powerful PDF generation API with no rate limits or file size constraints. Api2Pdf runs on AWS Lambda, a serverless architecture powered by Amazon to scale to millions of requests while being up to 90% cheaper than alternatives. Supports wkhtmltopdf, Headless Chrome, LibreOffice, and PDF Merge. You can also generate barcodes with ZXING (Zebra Crossing).
SDKs & Client Libraries
We've made a number of open source libraries available for the API
Python: https://github.com/api2pdf/api2pdf.python
.NET: https://github.com/api2pdf/api2pdf.dotnet
Nodejs: https://github.com/api2pdf/api2pdf.node
PHP: https://github.com/Api2Pdf/api2pdf.php
Ruby: (Coming soon)
Authorization
Create an account at portal.api2pdf.com to get an API key.
Authorize your API calls
GET requests, include apikey=YOUR-API-KEY as a query string parameter
POST requests, add Authorization to your header.
For more advanced usage and settings, see the API specification below.
Api2Pdf is a powerful PDF generation API with no rate limits or file size constraints. Api2Pdf runs on AWS Lambda, a serverless architecture powered by Amazon to scale to millions of requests while being up to 90% cheaper than alternatives. Supports wkhtmltopdf, Headless Chrome, LibreOffice, and PDF Merge. You can also generate barcodes with ZXING (Zebra Crossing).
SDKs & Client Libraries
We've made a number of open source libraries available for the API
Python: https://github.com/api2pdf/api2pdf.python
.NET: https://github.com/api2pdf/api2pdf.dotnet
Nodejs: https://github.com/api2pdf/api2pdf.node
PHP: https://github.com/Api2Pdf/api2pdf.php
Ruby: (Coming soon)
Authorization
Create an account at portal.api2pdf.com to get an API key.
Authorize your API calls
GET requests, include apikey=YOUR-API-KEY as a query string parameter
POST requests, add Authorization to your header.
For more advanced usage and settings, see the API specification below.
Local Search Client
microsoft.com
The Local Search client lets you send a search query to Bing and get back search results that include local businesses such as restaurants, hotels, retail stores, or other local businesses. The query can specify the name of the local business or it can ask for a list (for example, restaurants near me).
Interzoid Global Page Load Performance API
This API provides a timed, browser-simulated page load function (or a measured API call) from the specified geography using a server from that geography.
Airbyte Configuration API
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.
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.
Snyk API
snyk.io
The Snyk API is available to customers on paid plans and allows you to programatically integrate with Snyk.
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:
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:
Patchman-engine API
redhat.local
API of the Patch application on cloud.redhat.com
Syntax of the filtername] query parameters is described in [Filters documentation
Syntax of the filtername] query parameters is described in [Filters documentation
ConfigCat Public Management API
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.
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.
PowerTools Developer
Apptigent PowerTools Developer Edition is a powerful suite of API endpoints for custom applications running on any stack. Manipulate text, modify collections, format dates and times, convert currency, perform advanced mathematical calculations, shorten URL's, encode strings, convert text to speech, translate content into multiple languages, process images, and more. PowerTools is the ultimate developer toolkit.