Detailed API Endpoints (Examples)

Detailed API Endpoints (Examples)

Let’s outline some example endpoints to illustrate how a developer might use the CRE8 API:

• Authentication & User:

  • POST /api/v1/auth/request_login: Developer sends the user’s wallet address, gets a nonce back.

  • POST /api/v1/auth/verify_login: Developer sends the signature of the nonce (signed by the user’s wallet) to verify ownership. Gets back an API token or session cookie.

  • GET /api/v1/user/me: Get details of the authenticated user (profile info, linked wallet, etc.).

• Listing Services:

  • POST /api/v1/listings: Create a new service listing. Body might include JSON:

    
      "title": "Logo Design Package",
      "description": "Professional logo design with 3 revisions.",
      "price": 50,
      "currency": "USDC",
      "category": "Design",
      "duration": 7  // estimated delivery days
    }

    Response might contain a listing_id and the on-chain token mint address that was created, along with any transaction details of the mint.

    • GET /api/v1/listings/{listing_id}: Retrieve details of a specific listing (including status: available, sold, etc., and metadata).

    • GET /api/v1/listings?seller_wallet={wallet}: Query listings by a certain seller or other filters.

• Marketplace & Search:

  • GET /api/v1/marketplace/search?query=logo&min_price=0&max_price=100&sort=rating – returns a list of listings matching the search criteria.

  • GET /api/v1/categories – list of service categories and counts, etc.

• Order/Escrow Management:

  • POST /api/v1/orders: Initiate a purchase. Developer provides listing_id and maybe a buyer_wallet (if not derived from auth). The system responds with something like a Solana transaction payload or an escrow account address. Possibly the API could also handle a meta-transaction: where the developer requests the platform to facilitate the trade. However, since real payment needs signing, likely the API returns data to help the client craft the transaction.

    • It might return a structured blob (or use Solana Pay protocol) that the buyer’s wallet can use to complete the payment into escrow.

  • GET /api/v1/orders/{order_id}: Check the status of an order. Responds with status (in_progress, delivered, completed, disputed, etc.), and relevant addresses (escrow account, token mint).

  • POST /api/v1/orders/{order_id}/deliver: (Authenticated as seller) mark the order as delivered. This might trigger an on-chain transaction call under the hood (moving state in the escrow program).

  • POST /api/v1/orders/{order_id}/confirm: (Authenticated as buyer) confirm completion, which triggers escrow release. Alternatively, these actions might be done purely on-chain by calling the program, but providing an API endpoint can simplify for external integrations by wrapping the Solana calls.

  • POST /api/v1/orders/{order_id}/dispute: Flag a dispute. Perhaps requires some data or triggers an off-chain workflow for support.

• Review:

  • POST /api/v1/orders/{order_id}/review: Submit a review for that order (and thus for the seller). Body: rating + text.

  • GET /api/v1/users/{seller_wallet}/reviews: Fetch reviews for a particular provider.

• Wallet & Payments:

  • GET /api/v1/wallet/balances: Get the user’s balances for various currencies (as tracked by platform, though if non-custodial, this might just call blockchain or use an indexer).

  • POST /api/v1/wallet/deposit: If the platform allows depositing funds to a custodial account (some users might opt to pre-fund an account for convenience), this could generate a deposit address or instructions.

  • POST /api/v1/wallet/withdraw: Withdraw from custodial to personal wallet (again, only if there's a custodial option; if fully non-custodial, these may not exist).

These are hypothetical but illustrate the kind of endpoints expected. All API calls would require proper authentication and authorization. For instance, only the buyer of an order can call confirm on that order, etc. The API likely uses JWT tokens issued after wallet login, or API keys for server-to-server integration.