Closed MarketMadi closed 3 days ago
basically
These are the endpoints being consumed by FE:
Method | Endpoint | Description |
---|---|---|
POST | /api/register | Register a new user |
POST | /api/login | Authenticate a user |
GET | /api/orders | Fetch all orders |
POST | /api/orders/take | Take an existing order |
POST | /api/check-and-create-chatroom | Check and create a chatroom for an order |
GET | /api/orders/:orderId | Fetch details of a specific order |
GET | /api/invoice/:orderId | Fetch invoice for a specific order |
POST | /api/holdinvoicelookup | Check the status of a hold invoice |
PUT | /api/orders/:orderId | Update a specific order |
POST | /api/get-invoice | Get or create an invoice |
POST | /api/taker-invoice/${orderId} | Create a taker invoice for an order |
POST | /api/payouts | Submit a payout |
POST | /api/taker-full-invoice/${orderId} | Create a full invoice for a taker |
GET | /api/full-invoice/${orderId} | Fetch full invoice for an order |
GET | /api/order/${orderId}/latest-chat-details | Fetch latest chat details for an order |
GET | /api/currencies.json | Fetch available currencies |
Endpoints not consumed:
Method | Endpoint | Description |
---|---|---|
POST | /api/check-accepted-invoices | Check and update accepted invoices |
POST | /api/update-accept-offer-url | Update accept-offer URL |
POST | /api/settle/settle-hold-invoices | Settle hold invoices for an order |
POST | /api/orders/settle-holdinvoices-by-order | Settle hold invoices by order ID |
POST | /api/submitToMainstay | Submit data to Mainstay |
ive added those to readme so we dont lose track
https://github.com/civkit/civkit-api/pull/29
ill close this ticket. nice work.
We need to have a list of all needed endpoints.
User Registration and Authentication Endpoint: POST /api/users/create Purpose: Allows users to register by creating a unique avatar linked to a private token, which is stored securely for user recovery purposes.
Order Creation Endpoint: POST /api/orders/create Purpose: Allows a user (e.g., Alice) to create a new order to buy or sell Sats. This includes submitting a hold invoice that acts as a bond to secure the order.
Order Matching Endpoint: POST /api/orders/take Purpose: Enables another user (e.g., Bob) to take an existing order from the order book. Bob submits a hold invoice as his bond, finalizing the contract between the two parties.
Trade Execution Endpoints: Posting Trade: POST /api/trades/post Purpose: Bob posts the traded Sats using a hold invoice, initiating the transfer process. Submitting Payout Invoice: POST /api/payouts/submit Purpose: Alice submits her payout invoice for the fiat payment, which Bob needs to fulfill.
Payment Process Endpoint: POST /api/payments/confirm Purpose: Both parties confirm the receipt of fiat payment through a secure channel. This is crucial for releasing the hold on the bonded Sats and completing the transaction.
Trade Completion Endpoint: POST /api/trades/complete Purpose: Bob charges the trade hold invoice, completing the transfer of Sats to Alice. This process also involves returning the bonded amounts to both parties if all conditions are met without disputes.
Dispute Resolution Endpoint: POST /api/disputes/open Purpose: Handles any disputes that arise during the transaction process. This can lead to the charging (forfeiture) of bonds in case of cheating or unilateral cancellations. Database Design: Each of these processes is supported by a robust database structure:
Users Table: Manages user information and authentication tokens. Orders Table: Tracks all orders with details about user involvement and bond status. Trades Table: Records trade details, including Sats amounts and associated invoices. Payments Table: Monitors the status of fiat payments and confirmations. Disputes Table: Manages information related to any disputes, including outcomes and impacts on bonds. This summary provides a clear view of how each API endpoint contributes to the platform’s operation, ensuring that all aspects of a trade, from initiation to completion, are handled efficiently and securely.