API Documentation:

The DUOpenMarket Desktop Client, is a .NET Framework application which utilizes API calls to our public server, as detailed here.
The DUOM Client and API server are always under constant development, and things may change. There is no guarantee that what works today will work tomorrow.

ALL requests sent to the API server MUST be an HTTPS-secured GET Request. All other request types will fail with a 403 Error (Method Not Supported) response.
ALL requests are sent to and processed from the Base URL: https://duopenmarket.com/openmarketapi.php/
ALL commands or API functions, are merely extensions of this Base URL, created by appending the commands as strings.

Supported Client Protocol:

Before any script or program attempts to connect to the API server, it is "best practice" to first verify that the server's method of communication has not changed.
This can be done by sending the server one of two simple commands, which will provide a brief response from the server regardless of login status.
These commands are:

version - Responds with the current version number of the API running on the server.
minversion - Responds with the earliest version number of the API which is still understood by the server.

Example usage: https://duopenmarket.com/openmarketapi.php/minversion

Authorization Overview:

The server uses Discord OAuth's Code Grant Flow to verify and authorize user access using Discord's servers.
Before any user can attempt to retrieve or submit any data to the server, the authorization flow must first be completed.

Connecting to the server:

The first step in this process, is to open a browser window for the user, and navigate to: https://duopenmarket.com/discordclientGetAuthCode.php
This will automatically redirect the user to an Oauth login page provided by Discord, where the user must click "Authorize" to recieve an access code.

Since the API is only intended to work with the DUOM client, Discord uses a callback to a locally hosted server on port 43296 to send us the access code and state.
If you are using your own script or application, recreating this callback server or setting up a listener on port 43296 may be required.
As long as the recieved code and state can be retrieved from a browser and provided to your application, any method of doing this will work.
Once you have the access code, it should be used as the next piece of the URL Base string, and must always be included before any commands sent.

Example Listener Request: localhost:43296:?&code=testestestestestestestestestest&state=thiscanbeignored;
In this example we use the piece of the URL "testestestestestestestestestest" as our access code.

Example API call URL: https://duopenmarket.com/openmarketapi.php/testestestestestestestestestest/

Sending commands:

Now that we have an access_code, we can begin to send and retrieve data from the API server.
The available commands are a standard CRUD-interface, and a History command;
Arguments marked with an asterisk (*) are required and must not be empty.

Create - Accepts 8 arguments, orderid*, marketid*, itemid*, quantity*, ordertype*, expiration*, lastupdated*, and price*.
Read - Accepts 7 arguments, orderid, itemid*, marketid, minimum price, maximum price, minimum quantity, and maximum quantity.
Update - Accepts 8 arguments, orderid*, marketid, itemid, quantity, ordertype, expiration, lastupdated, and price.
Delete - Accepts 1 argument, the orderid* to be deleted.
History - Accepts 3 aruments, itemid*, marketid*, entires*.

(For history requests, entries should be the number of desired returned results, plus one. So for 7 days history, you would set entries to 8.)

Example: https://duopenmarket.com/openmarketapi.php/testestestestestestestestestest/read?itemid=1
Example: https://duopenmarket.com/openmarketapi.php/testestestestestestestestestest/history?itemid=1&market=1&entries=8

Server Response:

The server sends responses back in the form of JSON encoded strings. In the event that any errors have ocurred, the response string will simply contain the error code thrown and a description of the error if available.

If the request is processed successfully, the response may vary depending on the command issued. If you sent a Create, Update, or Delete request, the response code will simply be a "true" value to indicate the operation was successful.
A false value, likewise, would indicate that for whatever reason the server chose not to complete your request. Perhaps the operation was redundant? (creating an order which already exists, or deleting one which does not)

For Read requests, the returned JSON string will be the data for all entries matching the critera provided. (orderid should be specified for indexing specific orders)
A returned false value would indicate that no order entries could be found which matched the critera provided.

For History requests, the returned JSON string will contain as many entries as were requested, starting from the previous day.

Considerate Use:

Prior to sending Create, Update, or Delete requests, the user is expected to;

Create - First verify the order does not already exist on the server, and that the information is accurate and *should* be created. Creating falsified entries, or recreating old entries, may potentially get you banned from the service.
Update - First verify the order already exists on the server, and that it contains data which is older than the data you are uploading (lastupdate field should be cross referenced, only the newer copy should be taken)
Delete - First verify the order exists on the server, and should not. The criteria for this is either the current time is past the orders expiration, OR the order no longer appears in the logs created by the game for a given item.

Read requests are unthrottled, though if we notice an insane disparity in the ratio of Reads compared to Creates or Updates, this is indicative to us of someone leeching off our server's data without contributing anything, such users may be cut off from the service.

That's all for now. More information and details will be added as needed.