kylefang/prodigyapi
1
0
Fork 0
mirror of https://github.com/placeholder-soft/prodigyapi.git synced 2026-03-26 10:14:06 +08:00
Code Issues Packages Projects Releases Wiki Activity

JM03172023

Browse Source
This commit is contained in:
jasonzm46
2023-03-17 06:58:33 -07:00
parent 6f16031bf7
commit 0a2364edbd
1 changed files with 397 additions and 237 deletions
Download Patch File Download Diff File Expand all files Collapse all files

634
source/index.html.md
View File

@@ -5,8 +5,7 @@ language_tabs: # must be one of https://github.com/rouge-ruby/rouge/wiki/List-of
- plaintext
toc_footers:
- <a href='#'>Sign Up for a Developer Key</a>
- <a href='https://github.com/slatedocs/slate'>Documentation Powered by Slate</a>
- <a href='https://prodigy.fi'>Prodigy Protocol</a>
includes:
- errors
@@ -17,78 +16,58 @@ code_clipboard: true
meta:
- name: description
content: Documentation for the Prodigy API
- content: Documentation for the Prodigy Protocol API
---
# Prodigy API Documentation
//START of section - Do NOT copy this section to CMS//
This is Work in Progress documentation for the Prodigy API suite. The current structure of this document is a mix of competitive and first party content. The overall structure and content will change significantly.
## <b> Overview </b>
Customers will use our API to post and get information. There will be multiple APIs to document. A customer may use one or more of these APIs to complete tasks within our system.
<b> APIs to be documented </b>
API | Description
--------- |------------
FIX | FIX (Financial Information eXchange) API is a messaging protocol that is commonly used in the electronic trading industry to enter orders, submit cancel requests, and receive fills. This is intended to be used in conjunction with the FIX 4.4 Protocol Specification.
Websocket |The WebSocket API makes it possible to open a two-way interactive communication session between the user's browser and a server. With this API, you can send messages to a server and receive event-driven responses without having to poll the server for a reply.
stunnel | Stunnel is a proxy designed to add TLS encryption functionality to existing clients and servers without any changes in the programs' code. Stunnel uses the OpenSSL library for cryptography, so it supports whatever cryptographic algorithms are compiled into the library.
<b>Style</b>
The final documentation should adhere to the following conventions:
Minimal prose. Keep the prose simple and functional. APIs are typically used by subject matter experts, thus the syntax and code are most important and should not be buried within or after long prose explanations.
San-serif font for prose, serif for code.
Precise coding examples that can be copied for ease of use. Code must be properly indented.
If there are multiple steps in a process, provide an overview of each step before the detailed example for each.
Clear mathematical formulae where applicable. (Mathematical formulae will more likely appear in our application documentation.)
//END of section//
# <b>Table of Contents</b>
Overview
Websocket API
Currently Supported Instruments
Connectivity (alpha)
Authorization
Depth of Market Subscription (depth)
Price Info Subscription (price_info)
Websocket Availability
Websocket FAQ
stunnel Connectivity
Setup a client-side stunnel to connect to Prodigy’s CLOB
FIX API
Logon <A>
Anatomy of a Logon Message
Logout <5>
Anatomy of a Logout Message
NewOrderSingle <D>
Anatomy of a NewOrderSingle Message
OrderCancelRequest <F>
Anatomy of a OrderCancelRequest Message
OrderMassStatus <AF>
Anatomy of a OrderMassStatus Message
TradeCaptureReportRequest <AD>
Anatomy of a TradeCaptureReportRequest Message
# <b> Overview </b>
This document describes the API for the Prodigy decentralized exchange.
This document describes the API for the Prodigy Protocol platform.
By using any API provided by Prodigy, you agree to its Terms of Use and Privacy Policy.
## Currently Supported Instruments
BTC-USD: Bitcoin/USD spot price
* BTC-USD: Bitcoin/USD spot price
# Depth of Market Subscription (depth)
# Websocket API
## Connectivity (alpha)
wss://clob-alpha.dura.fi:36821
## Authorization
Please contact your Prodigy representative to request an Alpha CLOB token for your connectivity.
No additional authorization is required at this time.
After receiving your token, ensure that it is placed in the token field of your subscription request.
Token example with characters rewritten: `0xdaaf5b74xxx8afd78xxxxx2eb5db442edb53d760ea16xxxc67707xxxxxc925e4`
## Websocket Availability
* Sunday evening to Saturday evening EST.
* Currently includes a maintenance window on Thursday afternoons.
* Alpha environment times are not guaranteed.
## Websocket FAQ
Q. I am getting an ERROR: `token wasn't supplied`?
A. Token value must be supplied with the ws subscribeMessage for authentication.
Q. Why is the price of BTC 10x more than it should be and what is the “denominator” value in the response?
A. The denominator value is the factor to which we need to divide price by to derive the USD value of the asset. For example:
if "BestBidPrice" :"242385" , "Denominator":"10" & "Symbol":"BTC-USD" then the
USD price of BTC is $24,238.5
Q. What are the different responses coming from the depth ws connection?
A. Aside from confirmation of the connection being established, the initial depth data message will detail the current depth of the market at each price level on both the buy and sell side. Subsequent messages will update depth at those price levels based on actions taken by market participants. These actions can be new orders being added, existing orders being canceled, modified, or taken.
# Depth of Market subscription (depth)
Gets depth data for a market.
## Subscribe Message
Gets depth data for a market.
```plaintext
{
@@ -100,41 +79,27 @@ Gets depth data for a market.
};
```
## Response
The initial depth data response returns information about the market and its current buy and sell levels with data that describes the depth at each level.
Data | Definition
--------- |------------
Denominator | Factor to divide <Price> by for USD value
available | true
=======
# Depth of Market Subscription (depth)
Gets depth data for a market.
## Subscribe Message
Gets depth data for a market.
```plaintext
{
'user': 'g',
'action': 'subscribe',
'type': 'depth',
'value': ['BTC-USD'],
"token":"<provided by Prodigy>"
};
```
## Response
The initial depth data response returns information about the market and its current buy and sell levels with data that describes the depth at each level.
Data | Definition
--------- |------------
Denominator | Factor to divide <Price> by for USD value
available | true
DisplaySymbol | Display symbol of market
SecurityID | Exchange ID for market
Symbol | Symbol of market
buy_levels | Array of buy orders by level (details for each below)
&nbsp;&nbsp;&nbsp;NumOfOrders | Number of orders at this buy level
&nbsp;&nbsp;&nbsp;Price | Price of orders at this buy level
&nbsp;&nbsp;&nbsp;Qty | Quantity of orders at this buy level
sell_levels | Array of sell orders by level (details for each below)
&nbsp;&nbsp;&nbsp;NumOfOrders | Number of orders at this sell level
&nbsp;&nbsp;&nbsp;Qty | Price of orders at this sell level
&nbsp;&nbsp;&nbsp;sell_levels | Quantity of orders at this sell level
Example response:
```plaintext
{
@@ -159,193 +124,388 @@ available | true
...],
},
"Type":3
}
```
Use the `Logon <A>` message to authenticate a user establishing a connection to a remote system. The `Logon <A>` message must be the first message sent by the application requesting to initiate a FIX session.
## Subsequent Responses
Updates depth data for a market. Subsequently, depth data responses return updates to the depth of the market.
Data | Definition
--------- |------------
Denominator | Factor to divide <Price> by for USD value
DisplaySymbol | Display symbol of market
SecurityID | Exchange ID for market
Symbol | Symbol of market
updates | Array of updates to market depth (details for each below)
&nbsp;&nbsp;&nbsp;Action | Action that updated market depth (New, Delete, Add, Change)
&nbsp;&nbsp;&nbsp;NumOfOrders | Number of orders that were updated
&nbsp;&nbsp;&nbsp;Price | Price level of orders that were updated
&nbsp;&nbsp;&nbsp;Qty | Quantity of securities that were updated
&nbsp;&nbsp;&nbsp;Side | Side of the market of this update (Buy / Sell)
Example message response:
```plaintext
{
"data": {
"Denominator":"100",
"DisplaySymbol":"BTC-USD",
"SecurityID":"1000000189",
"Symbol":"BTC-USD",
"updates": [
{
"Action": "New",
"NumOfOrders": "1",
"Price": "2037900",
"Quantity": "500000",
"Side": "Buy",
},
{
"Action": "Change",
"NumOfOrders": "9",
"Price": "2056150",
"Quantity": "6160000",
"Side": "Sell",
}
],
},
"Type":4
}
```
## Price Info Subscription (price_info)
Gets price data for a market.
### Subscribe Message
```plaintext
{
'user': 'g',
'action': 'subscribe',
'type': 'price_info',
'value': ['BTC-USD'],
"token":"<provided by Prodigy>"
};
```
### Response
Data | Definition
--------- |------------
BestBidPrice | Price level of best bid
BestBidQty | Quantity available at best bid
BestOfferPrice | Price level of best ask
BestOfferQty | Quantity available at best ask
Denominator | Factor to divide <Price> by for USD value
LastTradePrice | Price that last trade executed
LastTradeQty | Quantity of last trade
LastTradeTimestamp | Linux timestamp of last trade
Symbol | Symbol of market
Example message response:
```plaintext
{
"data": {
"BestBidPrice":"242385",
"BestBidQty":"59300",
"BestOfferPrice":"242390",
"BestOfferQty":"200",
"Denominator":"10",
"LastTradePrice":"242385",
"LastTradeQty":"97",
"LastTradeTimestamp":"1660498301",
"Symbol":"BTC-USD"
},
"Type":5
}
```
# stunnel Connectivity
Prodigy uses stunnel, an open-source implementation used widely as an SSL tunneling tool. Refer to http://www.stunnel.org for more information.
A stunnel provides a secure way to send FIX messages from your FIX client, over the internet, to Prodigy. The possibilities of implementing this will vary based on your existing FIX client setup, but in general it is simple:
FIX Client -> Client-side stunnel -> INTERNET -> Exchange-side stunnel -> <PLACE_HOLDER>
Below is a guide to using a dockerized stunnel implementation available to you from Prodigy.
## Setup a client-side stunnel to connect to Prodigy’s CLOB
<b>Important environment variables:</b>
### Important environment variables
`export CLOB_HOST=clob-alpha.prodigy`
`export STUNNEL_PORT=[THE_LOCAL_PORT_TO_OPEN]`
> NOTE: (Optional) If TCP port 36814 is in use, change the local tunnel port to an available one.
# Kittens
Alternatively, these environment variables can be passed in on the command line (see below).
## Get All Kittens
```ruby
require 'kittn'
api = Kittn::APIClient.authorize!('meowmeowmeow')
api.kittens.get
### Download Prodigy stunnel docker-compose.yml file
```plaintext
version: '3.9'
services:
stunnel:
#image: dweomer/stunnel
image: gitlab.dev.blockriver.tech:5050/gyeu/stunnel
container_name: stunnel
ports:
- ${STUNNEL_PORT:-36814}:${STUNNEL_PORT:-36814}
environment:
- STUNNEL_SERVICE=fixs-client
- STUNNEL_CLIENT=yes
- STUNNEL_ACCEPT=${STUNNEL_PORT:-36814}
- STUNNEL_CONNECT=${CLOB_HOST:-localhost}:36813
- STUNNEL_PSKSECRETS=/etc/stunnel/psk.txt
volumes:
- ./psk.dev.txt:/etc/stunnel/psk.txt:ro
logging:
driver: "json-file"
options:
max-size: "50m"
max-file: "10"
```
```python
import kittn
api = kittn.authorize('meowmeowmeow')
api.kittens.get()
### Build Docker container with the Prodigy stunnel docker-compose.yml file
`cd to/dir/that/contains/docker-compose.yml`
`docker-compose up docker-compose.yml`
This will keep the container running in the foreground and we can press ctrl-c at any time to stop it.
### Install docker and docker-compose
We advise installing Docker Desktop. While you can install Docker and Docker Compose, Docker Desktop is an easy-to-install application for your macOS, Linux, or Windows environment that enables you to build and share containerized applications and microservices. Installing Docker Desktop also includes docker-compose out of the box, along with Docker engine and Docker CLI. Installing Docker Desktop is the fastest and simplest way to get started.
Alternatively, if you prefer to run the container in the background, use the following command:
`docker-compose up -d docker-compose.yml`
If running the container in the background, remember to stop the stunnel container when not using it, as it will occupy the port until the container is terminated.
Update configuration of your FIX client
* target host = 127.0.0.1
* target port = 36814
# FIX API
FIX (Financial Information eXchange) API is a messaging protocol used in the electronic trading industry. It allows clients and brokers to enter orders, submit cancel requests, and receive fills. The Prodigy Protocol FIX API is intended to be used in conjunction with the FIX 4.4 Protocol Specification.
To establish a connection using the FIX protocol, clients and brokers use a software called FIX engines. At a predetermined start time, Client A and Broker B connect their FIX engines using a predetermined host and comp ID.
Authentication results over a secure FIX protocol ensuring privacy of data exchange. The authentication process provides privacy and a reliable FIX protocol for effective communication between clients and brokers throughout electronic trade. Responses are formatted as strings and given numerical tags for efficient communication between clients and brokers.
In all of the following example messages, the “Anatomy of” section displays the FIX tags in header, body, trailer format.
## `Logon <A>`
Use the `Logon <A>` message to authenticate a user establishing a connection to a remote system. The `Logon <A>` message must be the first message sent by the application requesting to initiate a FIX session.
The `HeartBtInt <108>` field is used to declare the timeout interval for generating heartbeats, with both sides holding the same value. The HeartBtInt <108> value should be agreed upon by the two firms, specified by the Logon initiator, and echoed back by the Logon acceptor.
Upon receipt of a `Logon <A>` message, the session acceptor will authenticate the party requesting connection and issue a `Logon <A>` message as acknowledgment that the connection request has been accepted. The acknowledgment `Logon <A>` can also be used by the initiator to validate that the connection was established with the correct party.
The session acceptor must be prepared to immediately begin processing messages after receipt of the `Logon <A>`. The session initiator can choose to begin transmission of FIX messages before receipt of the confirmation `Logon <A>`, however it is recommended to wait for the return `Logon <A>` message to accommodate encryption key negotiation.
The confirmation `Logon <A>` can be used for encryption key negotiation. If a session key is deemed to be weak, a stronger session key can be suggested by returning a `Logon <A>` message with a new key. This is only valid for encryption protocols that allow for key negotiation. (See the FIX Web Site's Application notes for more information on a method for encryption and key passing.)
The `Logon <A>` message can be used to specify the <code>MaxMessageSize <383></code> supported. This can be used to control fragmentation rules for very large messages which support fragmentation. It can also be used to specify the MsgTypes supported for both sending and receiving.
### Anatomy of a Logon Message
Payload Example
```plaintext
8=FIX.4.4 | 9=94 | 35=A | 49=ACCOUNT_MNEMONIC | 56=order_router | 34=1 | 52=20221007-15:49:42.769 | 98=0 | 108=30 | 141=Y | 10=112 |
```
```shell
curl "http://example.com/api/kittens" \
-H "Authorization: meowmeowmeow"
Where:
| Field | Value | Tag Name | Is Required | Definition |
|------------------|-------------------|-----|-------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| <MessageHeader> | | | Y | MsgType<35>=A |
| 8 | FIX 4.4 | BeginString | Y | FIX protocol version |
| 9 | 94 | BodyLength | Y | Message length in bytes |
| 35 | A | MsgType | Y | Message type is a Logon message |
| 49 | ACCOUNT_MNEMONIC | SenderCompID | Y | ID of party sending message |
| 56 | order_router | TargetCompID | Y | ID of party receiving message |
| 34 | 1 | MsgSeqNum | Y | Integer message sequence number |
| 52 | 20221007-14:49.769 | SendingTime | Y | Time of message |
| 98 | 0 | EncryptMethod | Y | Method of encryption |
| 108 | 30 | HeartBint | Y | 30 second interval between heartbeat messages |
| 141 | Y | ResetSeqNumFlag | Y | Indicates that both sides of the FIX session should restart sequence numbers |
| 10 | 112 | CheckSum | Y | Checksum of FIX message |
| 95 | RawData | RawDataLength | N | Required for some authentication methods |
| 96 | data | RawData | N | Required for some authentication methods |
| 789 | | NextExpectedMsgSeqNum | N | Optional, alternative via counterparty bi-lateral agreement message gap detection and recovery approach |
| 383 | | MaxMessageSize | N | Can be used to specify the maximum number of bytes supported for messages received |
| 384 | | NoMsgTypes | N | Specifies the number of repeating `RefMsgTypes <372>` specified |
| => 372 | | RefMsgType | N | Specifies a specific, supported `MsgType <35>`. Required if `NoMsgTypes <384>` is > 0. Should be specified from the point of view of the sender of the `Logon <A>` message. |
| => 385 | | MsgDirection | N | Indicates direction (send vs. receive) of a supported `MsgType <35>`. Required if `NoMsgTypes <384>` is > 0. Should be specified from the point of view of the sender of the `Logon <A>` message. |
| 464 | | TestMessageindicator | N | Can be used to specify that this FIX session will be sending and receiving 'test' vs. 'production' messages. |
| 553 | | Username | N | |
| 554 | | Password | N | Note: minimal security exists without transport-level encryption. |
| `<MessageTrailer>` | | | | |
## `Logout <5>`
Use the `Logout <5>` message to initiate or confirm the termination of a FIX session. If disconnection occurs without the exchange of Logout messages, this should be interpreted as an abnormal condition.
Before closing the session, the initiator of the Logout message should wait for the opposite side to respond with a confirming Logout message. This gives the remote end a chance to perform any necessary Gap Fill operations. If the remote side does not respond in an appropriate time frame, the session may be terminated.
After sending the Logout message, the initiator should not send any messages unless requested to do so by the logout acceptor via a `Resend Request <2>`.
### Anatomy of a Logout Message
Payload Example
```plaintext
8=FIX.4.4 | 9=66 | 35=5 | 49=ACCOUNT_MNEMONIC | 52=20221027-00:00:00.949 | 56=order_router | 10=027 |
```
```javascript
const kittn = require('kittn');
Where:
let api = kittn.authorize('meowmeowmeow');
let kittens = api.kittens.get();
| Field | Value | Tag Name | Is Required | Definition |
|-----|-----|-----|-----|-----|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
## `NewOrderSingle <D>`
Use the `New Order <D>` message type to electronically submit securities and forex orders to a broker for execution.
Orders can be submitted with special handling and execution instructions. Handling instructions refer to how the broker should handle the order on its trading floor (see `HandlInst <21>` field). Execution instructions contain explicit directions as to how the order should be executed (see `ExecInst <18>` field).
New Order messages received with the `PossResend <97>` flag set in the header should be validated by `ClOrdID <11>`. Implementations should also check order parameters (side, symbol, quantity, etc.) to determine if the order had been previously submitted. PossResends previously received should be acknowledged back to the client via an Execution - Status message. PossResends that were not previously received should be processed as a new order and acknowledged via an Execution - New message.
The value specified in the `TransactTime <60>` field should allow the receiver of the order to apply business rules to determine if the order is potentially "stale," for example, in the event that there have been communication problems.
The `OrdType <40>` field can be set to Market, Limit, Forex - Swap, or Previously Quoted, while the `Product <460>` field is set to 4 (CURRENCY).
To "take" an `IOI <6>` (or `Quote <S>`) from an ECN or exchange and not display the order on the book, the New Order message must contain the `TimeInForce <59>` field set to "ImmediateOrCancel" and an OrdType <40> field set to "Previously Indicated" ( or "Previously Quoted").
Anatomy of a NewOrderSingle Message
Payload Example
```plaintext
8=FIX.4.4 | 9=66 | 35=5 | 49=ACCOUNT_MNEMONIC | 52=20221027-00:00:00.949 | 56=order_router | 10=027 |
```
> The above command returns JSON structured like this:
```json
[
{
"id": 1,
"name": "Fluffums",
"breed": "calico",
"fluffiness": 6,
"cuteness": 7
},
{
"id": 2,
"name": "Max",
"breed": "unknown",
"fluffiness": 5,
"cuteness": 10
}
]
Where:
| Field | Value | Tag Name | Is Required | Definition |
|-----|-----|-----|-----|-----|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
## `OrderCancelRequest <F>`
Use the `Order Cancel Request <F>` message request to cancel all of the remaining quantity of an existing order. Note that the `Order Cancel/Replace Request <G>` should be used to partially cancel or reduce an order.
The request will only be accepted if the order can successfully be pulled back from the exchange floor without executing.
A cancel request is assigned a `ClOrdID <11>` and is treated as a separate entity. If rejected, the `ClOrdID <11>` of the cancel request will be sent in the `Cancel Reject <9>` message, as well as the `ClOrdID <11>` of the actual order in the `OrigClOrdID <41>` field. The `ClOrdID <11>` assigned to the cancel request must be unique amongst the `ClOrdID <11>` assigned to regular orders and replacement orders.
### Anatomy of a OrderCancelRequest Message
Payload Example
```plaintext
8=FIX.4.4 | 9=197 | 35=F | 49=EIB_TRADER1_EMAIL_COM | 56=order_router | 34=6 | 52=20221103-05:15:53.225 | 41=ACC_OO1-1567450006911 | 11=ACC_001_1667450006914 | 1=SCC_001 55=BTC-USD | 48=1000000189 | 54=1 | 60=20221103-04:33:27.139 | 38=69 | 10=238
```
This endpoint retrieves all kittens.
Where:
### HTTP Request
| Field | Value | Tag Name | Is Required | Definition |
|-----|-----|-----|-----|-----|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
`GET http://example.com/api/kittens`
### Query Parameters
## `OrderMassStatus <AF>`
Parameter | Default | Description
--------- | ------- | -----------
include_cats | false | If set to true, the result will also include cats.
available | true | If set to false, the result will include kittens that have already been adopted.
The `Order Mass Status Request <AF>` message requests the status of orders that match the criteria specified in the request.
<aside class="success">
Remember — a happy kitten is an authenticated kitten!
</aside>
A mass status request is assigned `ClOrdID <11>` and is treated as a separate entity. Upon processing the request, ExecutionReports with `ExecType <150>`="Order Status" are returned for all orders matching the criteria provided on the request.
## Get a Specific Kitten
Use the `MassStatusReqType <585>` field to specify the selection criteria for the orders to be included upon the request.
```ruby
require 'kittn'
### Anatomy of a OrderMassStatus Message
api = Kittn::APIClient.authorize!('meowmeowmeow')
api.kittens.get(2)
Payload Example
```plaintext
8=FIX.4.4 | 9=93 35=AF | 49=EIB_TRADER1_EMAIL_COM | 56=order_router | 34=5. | 52=20221103-05:15:40.884 | 584=4 | 585=7 | 1=* | 10=039
```
```python
import kittn
Where:
api = kittn.authorize('meowmeowmeow')
api.kittens.get(2)
| Field | Value | Tag Name | Is Required | Definition |
|-----|-----|-----|-----|-----|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
## `TradeCaptureReportRequest <AD>`
Use the `Trade Capture Report Request <AD>` to:
* Request one or more trade capture reports based on specific selection criteria provided on the trade capture report request
* Subscribe for trade capture reports based upon selection criteria provided on the trade capture report request.
Except for `TradeRequestID <568>` and `SubscriptionRequestType <263>`, each field in the Trade Capture Report Request <AD> identifies filters. After meeting all specified filters, trade reports will be returned. Note that the filters are combined using an implied "and" - a trade report must satisfy every specified filter to be returned.
After looking at the `TradeCaptureReportRequest` in the example section below, notice the response sent back to the client is an execution report that matches the filters and queries in the original TradeCaptureReportRequest.
### Anatomy of a `TradeCaptureReportRequest` Message
Payload Example
```plaintext
8=FIX.4.4 | 9=117 | 35=AD | 34=3 | 49=EIB_TRADER1_EMAIL_COM | 52=20221103-05:15:40.884 | 56=order_router | 1=* | 58=* | 100=* | 568=T21666588915 | 569=0 | 10=137
```
```shell
curl "http://example.com/api/kittens/2" \
-H "Authorization: meowmeowmeow"
```
```javascript
const kittn = require('kittn');
let api = kittn.authorize('meowmeowmeow');
let max = api.kittens.get(2);
```
> The above command returns JSON structured like this:
```json
{
"id": 2,
"name": "Max",
"breed": "unknown",
"fluffiness": 5,
"cuteness": 10
}
```
This endpoint retrieves a specific kitten.
<aside class="warning">Inside HTML code blocks like this one, you can't use Markdown, so use <code>&lt;code&gt;</code> blocks to denote code.</aside>
### HTTP Request
`GET http://example.com/kittens/<ID>`
### URL Parameters
Parameter | Description
--------- | -----------
ID | The ID of the kitten to retrieve
## Delete a Specific Kitten
```ruby
require 'kittn'
api = Kittn::APIClient.authorize!('meowmeowmeow')
api.kittens.delete(2)
```
```python
import kittn
api = kittn.authorize('meowmeowmeow')
api.kittens.delete(2)
```
```shell
curl "http://example.com/api/kittens/2" \
-X DELETE \
-H "Authorization: meowmeowmeow"
```
```javascript
const kittn = require('kittn');
let api = kittn.authorize('meowmeowmeow');
let max = api.kittens.delete(2);
```
> The above command returns JSON structured like this:
```json
{
"id": 2,
"deleted" : ":("
}
```
This endpoint deletes a specific kitten.
### HTTP Request
`DELETE http://example.com/kittens/<ID>`
### URL Parameters
Parameter | Description
--------- | -----------
ID | The ID of the kitten to delete
Where:
| Field | Value | Tag Name | Is Required | Definition |
|-----|-----|-----|-----|-----|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |