ADVICEment's [DynamicDocs API automates your document generation](https://advicement.io/dynamic-documents-api) and creates dynamic, optimized, interactive PDFs. Write your templates in LaTeX and call the API with JSON data to get your PDFs in seconds. The template files are stored in your dashboard and can be edited, tested and published online. Document templates can contain dynamic text using logic statements, include tables stretching multiple pages and show great-looking charts based on the underlying data. LaTeX creates crisp, high-quality documents where every detail is well-positioned and styled. Integrate with ADVICEment DynamicDocs API in minutes and start creating beautiful [dynamic PDF documents](https://advicement.io/dynamic-documents-api) for your needs. For more information, visit [DynamicDocs API Home page](https://advicement.io/dynamic-documents-api).

RESTful API of [Request Baskets](https://rbaskets.in) service. Request Baskets is an open source project of a service to collect HTTP requests and inspect them via RESTful API or web UI. Check out the [project page](https://github.com/darklynx/request-baskets) for more detailed description.

Create beautiful product and API documentation with our developer friendly platform.

Catalog Inventory

API of the Patch application on [cloud.redhat.com](cloud.redhat.com) Syntax of the `filter[name]` query parameters is described in [Filters documentation](https://github.com/RedHatInsights/patchman-engine/wiki/API-custom-filters)

Remove the background of any image

RESTful API 4 Unipacker

Download OpenAPI specification: [openapi.yml](openapi.yml) # Introduction Rudder exposes a REST API, enabling the user to interact with Rudder without using the webapp, for example in scripts or cronjobs. ## Versioning Each time the API is extended with new features (new functions, new parameters, new responses, ...), it will be assigned a new version number. This will allow you to keep your existing scripts (based on previous behavior). Versions will always be integers (no 2.1 or 3.3, just 2, 3, 4, ...) or `latest`. You can change the version of the API used by setting it either within the url or in a header: * the URL: each URL is prefixed by its version id, like `/api/version/function`. ```bash # Version 10 curl -X GET -H "X-API-Token: yourToken" https://rudder.example.com/rudder/api/10/rules # Latest curl -X GET -H "X-API-Token: yourToken" https://rudder.example.com/rudder/api/latest/rules # Wrong (not an integer) => 404 not found curl -X GET -H "X-API-Token: yourToken" https://rudder.example.com/rudder/api/3.14/rules ``` * the HTTP headers. You can add the **X-API-Version** header to your request. The value needs to be an integer or `latest`. ```bash # Version 10 curl -X GET -H "X-API-Token: yourToken" -H "X-API-Version: 10" https://rudder.example.com/rudder/api/rules # Wrong => Error response indicating which versions are available curl -X GET -H "X-API-Token: yourToken" -H "X-API-Version: 3.14" https://rudder.example.com/rudder/api/rules ``` In the future, we may declare some versions as deprecated, in order to remove them in a later version of Rudder, but we will never remove any versions without warning, or without a safe period of time to allow migration from previous versions.

Existing versions

Version	Rudder versions it appeared in	Description
1	Never released (for internal use only)	Experimental version
2 to 10 (deprecated)	4.3 and before	These versions provided the core set of API features for rules, directives, nodes global parameters, change requests and compliance, rudder settings and system API
11	5.0	New system API (replacing old localhost v1 api): status, maintenance operations and server behavior
12	6.0 and 6.1	Node key management
13	6.2	Node status endpoint System health check System maintenance job to purge software [that endpoint was back-ported in 6.1]
14	7.0	Secret management Directive tree Improve techniques management Demote a relay
15	7.1	Package updates in nodes
16	7.2	Create node API included from plugin Configuration archive import/export

## Response format All responses from the API are in the JSON format. ```json { "action": "The name of the called function", "id": "The ID of the element you want, if relevant", "result": "The result of your action: success or error", "data": "Only present if this is a success and depends on the function, it's usually a JSON object", "errorDetails": "Only present if this is an error, it contains the error message" } ``` * __Success__ responses are sent with the 200 HTTP (Success) code * __Error__ responses are sent with a HTTP error code (mostly 5xx...) ## HTTP method Rudder's REST API is based on the usage of [HTTP methods](http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html). We use them to indicate what action will be done by the request. Currently, we use four of them: * **GET**: search or retrieve information (get rule details, get a group, ...) * **PUT**: add new objects (create a directive, clone a Rule, ...) * **DELETE**: remove objects (delete a node, delete a parameter, ...) * **POST**: update existing objects (update a directive, reload a group, ...) ## Parameters ### General parameters Some parameters are available for almost all API functions. They will be described in this section. They must be part of the query and can't be submitted in a JSON form. #### Available for all requests

Field	Type	Description
prettify	boolean optional	Determine if the answer should be prettified (human friendly) or not. We recommend using this for debugging purposes, but not for general script usage as this does add some unnecessary load on the server side. Default value: false

#### Available for modification requests (PUT/POST/DELETE)

Field	Type	Description
reason	string optional or required	Set a message to explain the change. If you set the reason messages to be mandatory in the web interface, failing to supply this value will lead to an error. Default value: ""
changeRequestName	string optional	Set the change request name, is used only if workflows are enabled. The default value depends on the function called Default value: A default string for each function
changeRequestDescription	string optional	Set the change request description, is used only if workflows are enabled. Default value: ""

### Passing parameters Parameters to the API can be sent: * As part of the URL for resource identification * As data for POST/PUT requests * Directly in JSON format * As request arguments #### As part of the URL for resource identification Parameters in URLs are used to indicate which resource you want to interact with. The function will not work if this resource is missing. ```bash # Get the Rule of ID "id" curl -H "X-API-Token: yourToken" https://rudder.example.com/rudder/api/latest/rules/id ``` CAUTION: To avoid surprising behavior, do not put a '/' at the end of an URL: it would be interpreted as '/[empty string parameter]' and redirected to '/index', likely not what you wanted to do. #### Sending data for POST/PUT requests ##### Directly in JSON format JSON format is the preferred way to interact with Rudder API for creating or updating resources. You'll also have to set the *Content-Type* header to **application/json** (without it the JSON content would be ignored). In a `curl` `POST` request, that header can be provided with the `-H` parameter: ```bash curl -X POST -H "Content-Type: application/json" ... ``` The supplied file must contain a valid JSON: strings need quotes, booleans and integers don't, etc. The (human readable) format is: ```json { "key1": "value1", "key2": false, "key3": 42 } ``` Here is an example with inlined data: ```bash # Update the Rule 'id' with a new name, disabled, and setting it one directive curl -X POST -H "X-API-Token: yourToken" -H "Content-Type: application/json" https://rudder.example.com/rudder/api/rules/latest/{id} -d '{ "displayName": "new name", "enabled": false, "directives": "directiveId"}' ``` You can also pass a supply the JSON in a file: ```bash # Update the Rule 'id' with a new name, disabled, and setting it one directive curl -X POST -H "X-API-Token: yourToken" -H "Content-Type: application/json" https://rudder.example.com/rudder/api/rules/latest/{id} -d @jsonParam ``` Note that the general parameters view in the previous chapter cannot be passed in a JSON, and you will need to pass them a URL parameters if you want them to be taken into account (you can't mix JSON and request parameters): ```bash # Update the Rule 'id' with a new name, disabled, and setting it one directive with reason message "Reason used" curl -X POST -H "X-API-Token: yourToken" -H "Content-Type: application/json" "https://rudder.example.com/rudder/api/rules/latest/{id}?reason=Reason used" -d @jsonParam -d "reason=Reason ignored" ``` ##### Request parameters In some cases, when you have little, simple data to update, JSON can feel bloated. In such cases, you can use request parameters. You will need to pass one parameter for each data you want to change. Parameters follow the following schema: ``` key=value ``` You can pass parameters by two means: * As query parameters: At the end of your url, put a **?** then your first parameter and then a **&** before next parameters. In that case, parameters need to be https://en.wikipedia.org/wiki/Percent-encoding[URL encoded] ```bash # Update the Rule 'id' with a new name, disabled, and setting it one directive curl -X POST -H "X-API-Token: yourToken" https://rudder.example.com/rudder/api/rules/latest/{id}?"displayName=my new name"&"enabled=false"&"directives=aDirectiveId" ``` * As request data: You can pass those parameters in the request data, they won't figure in the URL, making it lighter to read, You can pass a file that contains data. ```bash # Update the Rule 'id' with a new name, disabled, and setting it one directive (in file directive-info.json) curl -X POST -H "X-API-Token: yourToken" https://rudder.example.com/rudder/api/rules/latest/{id} -d "displayName=my new name" -d "enabled=false" -d @directive-info.json ```

Manage Runscope programmatically.

## Introduction The Shorten.rest API allows you to programmatically create short URLs (an 'alias') for longer URL (a 'destination'). Each alias you create can be used to redirect the end user (person clicking on the link) to one or more destination URLs A default destination is always set and specific destinations can be set to redirect the end user to preferred destinations based on the user's geographical location (country) and device Operating System. In order to use the Shorten.Rest URL Shortening API you can choose to bind your own branded domain, sub-domain or to use our default domain - Short.FYI ### Destination Matching When creating or editing a short URL ('alias') you can choose to specify a destination for each country and OS ([Supported OSes list](#tag/OperatingSystems)) combination. When a user clicks on the short link, Shorten.rest will examine the end user's country (determined by User's IP) and OS (User agent) and match the most suitable destination for each user. (*) If no destination is set for a specific request combination Shorten.rest will use the default destination that exists within each short URL (**) BRANDED DOMAINS: If the requested alias does not exist in our database - Shorten.rest will redirect the user to the default fallback you set within your dashboard under the ‘Alias Not Found Page Url’ value for a custom domain. (***) Operating System (OS) destinations are stronger than a country destination! For example - if you have a custom landing page that is targeting people in the USA and a second landing page that is hyper focused for people who use iOS devices - a person clicking on your link in the USA that is on an iPhone will be redirected to the iOS landing page, while all other devices will be redirected to the USA landing page. | OS | Country | Destination | | :------------: |:---------------:| -----| | iOS | | YourDestination.com/ios | | | US | YourDestination.com/usa | Shorten.rest will choose the YourDestination.com/ios url as the most suitable destination. ### Branded Domain Attributes When setting up your custom domain you can include optional metatags and snippets ([Supported snippets list](#tag/Snippets)). These parameters (such as retargeting, tracking and conversion pixels) are populated and fired on click - at the time of the redirect. By default the parameters you set in the domain setting will be included in all Short URLs associated with that domain. You can always override the domain defaults for each URL by passing the appropriate variables when creating or updating a short URL ### Setting a Custom string for an Alias (short.fyi/alias) While creating a short URL you can specify which domain to use. You can choose to use your own branded domain or our default domain - Short.fyi. Each Alias is unique within a domain they are related to. This means that if multiple accounts use you the same domain (for example short.fyi), if an alias is already taken you may not create a new destination for it. That said - If you would like to use a specific alias which is already taken - the only way to do so is to create it on a new domain you own and have attached to your Shorten.rest account. ### Random Aliases By default - unless you specify a vanity URI for your alias each URL that is shortened on our platform will have a random string generated by the API. This means that if the 'alias' attribute of a /aliases POST request is not provided, or is an empty string, a random string of seven characters will be generated and returned as part of the POST response. You can also place the @**rnd** macro within the alias field when you create a new alias, for example /vanity/@rnd, which might return an alias like /vanity/ZMAefRt, or /vanity@rnd, which might produce something like /vanityMRtvxadf. Only the first @rnd in an alias attribute will be replaced. ### NOTES ( * ) All methods of the Shorten.REST API require that your API key be provided in **x-api-key** header. (**) All API parameters are case sensitive

A plugin that allows users to interact with Slack using ChatGPT

The Snyk API is available to customers on [Business and Enterprise plans](https://snyk.io/plans) and allows you to programatically integrate with Snyk. ## REST API We are in the process of building a new, improved API (`https://api.snyk.io/rest`) built using the OpenAPI and JSON API standards. We welcome you to try it out as we shape and release endpoints until it, ultimately, becomes a full replacement for our current API. Looking for our REST API docs? Please head over to [https://apidocs.snyk.io](https://apidocs.snyk.io) ## 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](https://snyk.io/docs/using-snyk) 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](https://snyk.io/docs/). 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://api.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`: ```http Authorization: token API_KEY ``` Otherwise, a 401 "Unauthorized" response will be returned. ```http HTTP/1.1 401 Unauthorized { "code": 401, "error": "Not authorised", "message": "Not authorised" } ``` ## Overview and entities The API is a REST API. It has the following entities: ### Test result The test result is the object returned from the API giving the results of testing a package for issues. It has the following fields: | Property | Type | Description | Example | |----------------:|---------|-------------------------------------------------------|-----------------------------------------------------------------| | ok | boolean | Does this package have one or more issues? | false | | issues | object | The issues found. See below for details. | See below | | dependencyCount | number | The number of dependencies the package has. | 9 | | org | object | The organization this test was carried out for. | {"name": "anOrg", "id": "5d7013d9-2a57-4c89-993c-0304d960193c"} | | licensesPolicy | object | The organization's licenses policy used for this test | See in the examples | | packageManager | string | The package manager for this package | "maven" | | | | | | ### Issue An issue is either a vulnerability or a license issue, according to the organization's policy. It has the following fields: | Property | Type | Description | Example | |---------------:|---------------|----------------------------------------------------------------------------------------------------------------------------|----------------------------------------| | id | string | The issue ID | "SNYK-JS-BACKBONE-10054" | | url | string | A link to the issue details on snyk.io | "https://snyk.io/vuln/SNYK-JS-BACKBONE-10054 | | title | string | The issue title | "Cross Site Scripting" | | type | string | The issue type: "license" or "vulnerability". | "license" | | paths | array | The paths to the dependencies which have an issue, and their corresponding upgrade path (if an upgrade is available). [More information about from and upgrade paths](#introduction/overview-and-entities/from-and-upgrade-paths) | [
  {
    "from": ["a@1.0.0", "b@4.8.1"],
    "upgrade": [false, "b@4.8.2"]
  }
] | | package | string | The package identifier according to its package manager | "backbone", "org.apache.flex.blazeds:blazeds"| | version | string | The package version this issue is applicable to. | "0.4.0" | | severity | string | The Snyk defined severity level: "critical", "high", "medium" or "low". | "high" | | language | string | The package's programming language | "js" | | packageManager | string | The package manager | "npm" | | semver | array[string] OR map[string]array[string] | One or more [semver](https://semver.org) ranges this issue is applicable to. The format varies according to package manager. | ["<0.5.0, >=0.4.0", "<0.3.8, >=0.3.6"] OR { "vulnerable": ["[2.0.0, 3.0.0)"], "unaffected": ["[1, 2)", "[3, )"] } | ### Vulnerability A vulnerability in a package. In addition to all the fields present in an issue, a vulnerability also has these fields: Property | Type | Description | Example | ----------------:|---------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|------------------------------------------------| publicationTime | Date | The vulnerability publication time | "2016-02-11T07:16:18.857Z" | disclosureTime | Date | The time this vulnerability was originally disclosed to the package maintainers | "2016-02-11T07:16:18.857Z" | isUpgradable | boolean | Is this vulnerability fixable by upgrading a dependency? | true | description | string | The detailed description of the vulnerability, why and how it is exploitable. Provided in markdown format. | "## Overview\n[`org.apache.logging.log4j:log4j-core`](http://search.maven.org/#search%7Cga%7C1%7Ca%3A%22log4j-core%22)\nIn Apache Log4j 2.x before 2.8.2, when using the TCP socket server or UDP socket server to receive serialized log events from another application, a specially crafted binary payload can be sent that, when deserialized, can execute arbitrary code.\n\n# Details\nSerialization is a process of converting an object into a sequence of bytes which can be persisted to a disk or database or can be sent through streams. The reverse process of creating object from sequence of bytes is called deserialization. Serialization is commonly used for communication (sharing objects between multiple hosts) and persistence (store the object state in a file or a database). It is an integral part of popular protocols like _Remote Method Invocation (RMI)_, _Java Management Extension (JMX)_, _Java Messaging System (JMS)_, _Action Message Format (AMF)_, _Java Server Faces (JSF) ViewState_, etc.\n\n_Deserialization of untrusted data_ ([CWE-502](https://cwe.mitre.org/data/definitions/502.html)), is when the application deserializes untrusted data without sufficiently verifying that the resulting data will be valid, letting the attacker to control the state or the flow of the execution. \n\nJava deserialization issues have been known for years. However, interest in the issue intensified greatly in 2015, when classes that could be abused to achieve remote code execution were found in a [popular library (Apache Commons Collection)](https://snyk.io/vuln/SNYK-JAVA-COMMONSCOLLECTIONS-30078). These classes were used in zero-days affecting IBM WebSphere, Oracle WebLogic and many other products.\n\nAn attacker just needs to identify a piece of software that has both a vulnerable class on its path, and performs deserialization on untrusted data. Then all they need to do is send the payload into the deserializer, getting the command executed.\n\n> Developers put too much trust in Java Object Serialization. Some even de-serialize objects pre-authentication. When deserializing an Object in Java you typically cast it to an expected type, and therefore Java's strict type system will ensure you only get valid object trees. Unfortunately, by the time the type checking happens, platform code has already created and executed significant logic. So, before the final type is checked a lot of code is executed from the readObject() methods of various objects, all of which is out of the developer's control. By combining the readObject() methods of various classes which are available on the classpath of the vulnerable application an attacker can execute functions (including calling Runtime.exec() to execute local OS commands).\n- Apache Blog\n\n\n## References\n- [NVD](https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2017-5645)\n- [jira issue](https://issues.apache.org/jira/browse/LOG4J2-1863)\n" | isPatchable | boolean | Is this vulnerability fixable by using a Snyk supplied patch? | true | isPinnable | boolean | Is this vulnerability fixable by pinning a transitive dependency | true | identifiers | object | Additional vulnerability identifiers | {"CWE": [], "CVE": ["CVE-2016-2402]} | credit | string | The reporter of the vulnerability | "Snyk Security Team" | CVSSv3 | string | Common Vulnerability Scoring System (CVSS) provides a way to capture the principal characteristics of a vulnerability, and produce a numerical score reflecting its severity, as well as a textual representation of that score. | "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N" | cvssScore | number | CVSS Score | 5.3 | patches | array | Patches to fix this issue, by snyk | see "Patch" below. | upgradePath | object | The path to upgrade this issue, if applicable | see below | isPatched | boolean | Is this vulnerability patched? | false | exploitMaturity | string | The snyk exploit maturity level #### Patch A patch is an object like this one: ```json { "urls": [ "https://snyk-patches.s3.amazonaws.com/npm/backbone/20110701/backbone_20110701_0_0_0cdc525961d3fa98e810ffae6bcc8e3838e36d93.patch" ], "version": "<0.5.0 >=0.3.3", "modificationTime": "2015-11-06T02:09:36.180Z", "comments": [ "https://github.com/jashkenas/backbone/commit/0cdc525961d3fa98e810ffae6bcc8e3838e36d93.patch" ], "id": "patch:npm:backbone:20110701:0" } ``` ### From and upgrade paths Both from and upgrade paths are arrays, where each item within the array is a package `name@version`. Take the following `from` path: ``` [ "my-project@1.0.0", "actionpack@4.2.5", "rack@1.6.4" ] ``` Assuming this was returned as a result of a test, then we know: - The package that was tested was `my-project@1.0.0` - The dependency with an issue was included in the tested package via the direct dependency `actionpack@4.2.5` - The dependency with an issue was [rack@1.6.4](https://snyk.io/vuln/rubygems:rack@1.6.4) Take the following `upgrade` path: ``` [ false, "actionpack@5.0.0", "rack@2.0.1" ] ``` Assuming this was returned as a result of a test, then we know: - The package that was tested is not upgradable (`false`) - The direct dependency `actionpack` should be upgraded to at least version `5.0.0` in order to fix the issue - Upgrading `actionpack` to version `5.0.0` will cause `rack` to be installed at version `2.0.1` If the `upgrade` path comes back as an empty array (`[]`) then this means that there is no upgrade path available which would fix the issue. ### License issue A license issue has no additional fields other than the ones in "Issue". ### Snyk organization The organization in Snyk this request is applicable to. The organization determines the access rights, licenses policy and is the unit of billing for private projects. A Snyk organization has these fields: Property | Type | Description | Example | -----------:| ------ | ----------------------------- | -------------------------------------- | name | string | The organization display name | "deelmaker" | id | string | The ID of the organization | "3ab0f8d3-b17d-4953-ab6d-e1cbfe1df385" | ## Errors This is a beta release of this API. Therefore, despite our efforts, errors might occur. In the unlikely event of such an error, it will have the following structure as JSON in the body: Property | Type | Description | Example | -----------:| ------ | ----------------------------- | -------------------------------------- | message | string | Error message with reference | Error calling Snyk api (reference: 39db46b1-ad57-47e6-a87d-e34f6968030b) | errorRef | V4 uuid | An error ref to contact Snyk with | 39db46b1-ad57-47e6-a87d-e34f6968030b | The error reference will also be supplied in the `x-error-reference` header in the server reply. Example response: ```http HTTP/1.1 500 Internal Server Error x-error-reference: a45ec9c1-065b-4f7b-baf8-dbd1552ffc9f Content-Type: application/json; charset=utf-8 Content-Length: 1848 Vary: Accept-Encoding Date: Sun, 10 Sep 2017 06:48:40 GMT ``` ## Rate Limiting To ensure resilience against increasing request rates, we are starting to introduce rate-limiting. We are monitoring the rate-limiting system to ensure minimal impact on users while ensuring system stability. Current limit is up to 2000 requests per minute, per user. This limit is above industry standards, and is subject to change. As such, we recommend calls to the API are throttled regardless of the current limit. All requests above the limit will get a response with status code `429` - `Too many requests` until requests stop for the duration of the rate-limiting interval (currently a minute). ## Consuming Webhooks Webhooks are delivered with a `Content-Type` of `application/json`, with the event payload as JSON in the request body. We also send the following headers: - `X-Snyk-Event` - the name of the event - `X-Snyk-Transport-ID` - a GUID to identify this delivery - `X-Snyk-Timestamp` - an ISO 8601 timestamp for when the event occurred, for example: `2020-09-25T15:27:53Z` - `X-Hub-Signature` - the HMAC hex digest of the request body, used to secure your webhooks and ensure the request did indeed come from Snyk - `User-Agent` - identifies the origin of the request, for example: `Snyk-Webhooks/XXX` --- After your server is configured to receive payloads, it listens for any payload sent to the endpoint you configured. For security reasons, you should limit requests to those coming from Snyk. ### Validating payloads All transports sent to your webhooks have a `X-Hub-Signature` header, which contains the hash signature for the transport. The signature is a HMAC hexdigest of the request body, generated using sha256 and your `secret` as the HMAC key. You could use a function in Node.JS such as the following to validate these signatures on incoming requests from Snyk: ```javascript import * as crypto from 'crypto'; function verifySignature(request, secret) { const hmac = crypto.createHmac('sha256', secret); const buffer = JSON.stringify(request.body); hmac.update(buffer, 'utf8'); const signature = `sha256=${hmac.digest('hex')}`; return signature === request.headers['x-hub-signature']; } ``` ### Payload versioning Payloads may evolve over time, and so are versioned. Payload versions are supplied as a suffix to the `X-Snyk-Event` header. For example, `project_snapshot/v0` indicates that the payload is `v0` of the `project_snapshot` event. Version numbers only increment when a breaking change is made; for example, removing a field that used to exist, or changing the name of a field. Version numbers do not increment when making an additive change, such as adding a new field that never existed before. **Note:** During the BETA phase, the structure of webhook payloads may change at any time, so we recommend you check the payload version. ### Event types While consuming a webhook event, `X-Snyk-Event` header must be checked, as an end-point may receive multiple event types. #### ping The ping event happens after a new webhook is created, and can also be manually triggered using the ping webhook API. This is useful to test that your webhook receives data from Snyk correctly. The `ping` event makes the following request: ```jsx POST /webhook-handler/snyk123 HTTP/1.1 Host: my.app.com X-Snyk-Event: ping/v0 X-Snyk-Transport-ID: 998fe884-18a0-45db-8ae0-e379eea3bc0a X-Snyk-Timestamp: 2020-09-25T15:27:53Z X-Hub-Signature: sha256=7d38cdd689735b008b3c702edd92eea23791c5f6 User-Agent: Snyk-Webhooks/044aadd Content-Type: application/json { "webhookId": "d3cf26b3-2d77-497b-bce2-23b33cc15362" } ``` #### project_snapshot This event is triggered every time an existing project is tested and a new snapshot is created. It is triggered on every test of a project, whether or not there are new issues. This event is not triggered when a new project is created or imported. Currently supported targets/scan types are Open Source and container. ```jsx POST /webhook-handler/snyk123 HTTP/1.1 Host: my.app.com X-Snyk-Event: project_snapshot/v0 X-Snyk-Transport-ID: 998fe884-18a0-45db-8ae0-e379eea3bc0a X-Snyk-Timestamp: 2020-09-25T15:27:53Z X-Hub-Signature: sha256=7d38cdd689735b008b3c702edd92eea23791c5f6 User-Agent: Snyk-Webhooks/044aadd Content-Type: application/json { "project": { ... }, // project object matching API responses "org": { ... }, // organization object matching API responses "group": { ... }, // group object matching API responses "newIssues": [], // array of issues object matching API responses "removedIssues": [], // array of issues object matching API responses } ``` #### Detailed example of a payload ##### project see: [https://snyk.docs.apiary.io/#reference/projects](https://snyk.docs.apiary.io/#reference/projects) ```tsx "project": { "name": "snyk/goof", "id": "af137b96-6966-46c1-826b-2e79ac49bbd9", "created": "2018-10-29T09:50:54.014Z", "origin": "github", "type": "maven", "readOnly": false, "testFrequency": "daily", "totalDependencies": 42, "issueCountsBySeverity": { "low": 13, "medium": 8, "high": 4, "critical": 5 }, "imageId": "sha256:caf27325b298a6730837023a8a342699c8b7b388b8d878966b064a1320043019", "imageTag": "latest", "imageBaseImage": "alpine:3", "imagePlatform": "linux/arm64", "imageCluster": "Production", "hostname": null, "remoteRepoUrl": "https://github.com/snyk/goof.git", "lastTestedDate": "2019-02-05T08:54:07.704Z", "browseUrl": "https://app.snyk.io/org/4a18d42f-0706-4ad0-b127-24078731fbed/project/af137b96-6966-46c1-826b-2e79ac49bbd9", "importingUser": { "id": "e713cf94-bb02-4ea0-89d9-613cce0caed2", "name": "example-user@snyk.io", "username": "exampleUser", "email": "example-user@snyk.io" }, "isMonitored": false, "branch": null, "targetReference": null, "tags": [ { "key": "example-tag-key", "value": "example-tag-value" } ], "attributes": { "criticality": [ "high" ], "environment": [ "backend" ], "lifecycle": [ "development" ] }, "remediation": { "upgrade": {}, "patch": {}, "pin": {} } } ``` ##### org see: [https://snyk.docs.apiary.io/#reference/organizations](https://snyk.docs.apiary.io/#reference/organizations) ```tsx "org": { "name": "My Org", "id": "a04d9cbd-ae6e-44af-b573-0556b0ad4bd2", "slug": "my-org", "url": "https://api.snyk.io/org/my-org", "created": "2020-11-18T10:39:00.983Z" } ``` ##### group see: [https://snyk.docs.apiary.io/#reference/groups](https://snyk.docs.apiary.io/#reference/groups) ```tsx "group": { "name": "ACME Inc.", "id": "a060a49f-636e-480f-9e14-38e773b2a97f" } ``` ##### issue see: https://snyk.docs.apiary.io/#reference/users/user-organization-notification-settings/list-all-aggregated-issues ```tsx { "id": "npm:ms:20170412", "issueType": "vuln", "pkgName": "ms", "pkgVersions": [ "1.0.0" ], "issueData": { "id": "npm:ms:20170412", "title": "Regular Expression Denial of Service (ReDoS)", "severity": "low", "url": "https://snyk.io/vuln/npm:ms:20170412", "description": "Lorem ipsum", "identifiers": { "CVE": [], "CWE": [ "CWE-400" ], "ALTERNATIVE": [ "SNYK-JS-MS-10509" ] }, "credit": [ "Snyk Security Research Team" ], "exploitMaturity": "no-known-exploit", "semver": { "vulnerable": [ ">=0.7.1 <2.0.0" ] }, "publicationTime": "2017-05-15T06:02:45Z", "disclosureTime": "2017-04-11T21:00:00Z", "CVSSv3": "CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L", "cvssScore": 3.7, "language": "js", "patches": [ { "id": "patch:npm:ms:20170412:2", "urls": [ "https://snyk-patches.s3.amazonaws.com/npm/ms/20170412/ms_071.patch" ], "version": "=0.7.1", "comments": [], "modificationTime": "2019-12-03T11:40:45.866206Z" } ], "nearestFixedInVersion": "2.0.0" }, "isPatched": false, "isIgnored": false, "fixInfo": { "isUpgradable": false, "isPinnable": false, "isPatchable": true, "nearestFixedInVersion": "2.0.0" }, "priority": { "score": 399, "factors": [ { "name": "isFixable", "description": "Has a fix available" }, { "name": "cvssScore", "description": "CVSS 3.7" } ] } } ```

Stack Exchange is a network of 130+ Q&A communities including Stack Overflow.

This is an online swagger codegen server. You can find out more at https://github.com/swagger-api/swagger-codegen or on [irc.freenode.net, #swagger](http://swagger.io/irc/).

# Overview Use SwaggerHub Registry API to access, manage, and update the following resources in SwaggerHub, bypassing the web interface: * APIs * Domains * Integrations * Projects * Templates SwaggerHub also provides the [User Management API](https://app.swaggerhub.com/apis-docs/swagger-hub/user-management-api/) to get information about organizations and manage organization members. # Base URL Use the following base URL for SwaggerHub SaaS: http(s)://api.swaggerhub.com **Note:** This documentation is for SwaggerHub SaaS. On-Premise customers should use the bundled API definition, which can be found at the URLs provided below. Version 1.29.0 or later: http(s)://SERVER/v1/openapi.yaml - YAML version http(s)://SERVER/v1/openapi.json - JSON version Earlier versions: http(s)://SERVER/v1/swagger.yaml - YAML version http(s)://SERVER/v1/swagger.json - JSON version # Authentication Operations that update data or access private data require authentication using an API key. You can find your personal API key on the [API Keys](https://app.swaggerhub.com/settings/apiKey) page in your account settings. Send this key in the `Authorization` header when making requests to the Registry API: Authorization: YOUR_API_KEY To test API calls from this documentation page, click the **Authorize** button below and paste your API key there. **Important:** Keep the API key secure and do not store it directly in your code. # Tools In addition to calling the Registry API directly, you can use the following tools to interact with the API from the command line or CI/CD pipeline: * [SwaggerHub CLI](https://www.npmjs.com/package/swaggerhub-cli) * [Maven plugin](https://github.com/swagger-api/swaggerhub-maven-plugin) * [Gradle plugin](https://github.com/swagger-api/swaggerhub-gradle-plugin)

Paste a Long URL link to shorten it

A plugin that allows the user to capture screenshots of a web page from a URL or HTML using ChatGPT.

This API allows you to interact with the VictorOps platform in various ways. Your account may be limited to a total number of API calls per month. Also, some of these API calls have rate limits. NOTE: In this documentation when creating a sample curl request (clicking the TRY IT OUT! button), in some API viewing interfaces, the '@' in an email address may be encoded. Please note that the REST endpoints will not process the encoded version. Make sure that the encoded character '%40' is changed to its unencoded form before submitting the curl request.