Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/JuanSCaicedo/Api-Ecommerce/llms.txt

Use this file to discover all available pages before exploring further.

Every response from API Ecommerce is application/json. The API uses two broad response patterns found throughout the codebase: envelope responses that wrap the payload in named keys (e.g. "product", "carts", "sales"), and status-message responses that return a message key with an integer application-level code. Understanding both patterns is essential for correct client-side error handling.

​
Success responses

​
Resource created

Returned by write operations that create a new record. The HTTP status is 200 (except for user registration, which returns 201). The response includes the integer application code 200 in the message field and, where relevant, the new record’s database id. Source: Admin\Product\ProductController::store 
{
  "message": 200,
  "id": 42
}
​
message
integer
Application-level status code. 200 indicates success.
​
id
integer
The auto-incremented primary key of the newly created record. Present on product creation; omitted on other resource types.

​
Paginated resource list

Returned by admin index endpoints. The HTTP status is 200. Source: Admin\Product\ProductController::index 
{
  "total": 100,
  "products": [
    {
      "id": 1,
      "title": "Wireless Headphones",
      "slug": "wireless-headphones"
    }
  ]
}
​
total
integer
Total number of records across all pages, as returned by Laravel’s paginator.
​
products
array
Array of product resource objects for the current page (10 items per page).

​
Single object returned

Returned by show/detail endpoints. The HTTP status is 200. Source: Admin\Product\ProductController::show 
{
  "product": {
    "id": 1,
    "title": "Wireless Headphones",
    "slug": "wireless-headphones",
    "price": 99.99
  }
}
​
product
object
Full product resource object serialised by ProductResource.

​
Simple acknowledgement

Returned by write operations that do not need to return a payload — for example, completing checkout, deleting a cart item, or updating a profile. Source: Ecommerce\SaleController::store, Ecommerce\CartController::destroy 
{
  "message": 200
}
​
message
integer
Application-level status code. 200 indicates the operation completed successfully.

​
Error responses

​
Business logic error

When the API rejects an operation for a domain reason (e.g. duplicate product, item already in cart, stock exceeded, invalid coupon), it returns a JSON body with an integer message code and a human-readable message_text. The HTTP status code is 200 — the error is signalled at the application level, not the transport level.
The "message": 403 pattern is an application-level code embedded in a standard 200 OK HTTP response. It is not an HTTP 403 Forbidden. Your client must check the message field value, not only the HTTP status, to detect these business logic errors. This convention is consistent across all controllers in the codebase.
Source: Ecommerce\CartController::store (product already in cart) 
{
  "message": 403,
  "message_text": "El producto ya se encuentra en el carrito, intente modificando la cantidad en el carrito."
}
Source: Admin\Product\ProductController::store (duplicate title) 
{
  "message": 403,
  "message_text": "The product already exists"
}
​
message
integer
Application-level error code. 403 is used for business logic rejections across all controllers.
​
message_text
string
Human-readable description of the error. Admin controller messages are in English (e.g. "The product already exists"); storefront controller messages are in Spanish (e.g. "El producto ya se encuentra en el carrito...").
AuthController::update is the one exception: when the current password supplied is incorrect it returns a genuine HTTP 403 status (not a 200 with message: 403), along with the message/message_text body. All other message: 403 patterns in the codebase use HTTP 200.

​
Validation error

When request input fails Laravel’s Validator rules, the response has HTTP status 400 and a JSON body containing field-level error messages. Source: AuthController::register 
{
  "name": ["The name field is required."],
  "email": ["The email has already been taken."],
  "password": ["The password must be at least 8 characters."]
}
Each key is the name of the failing field; the value is an array of error message strings.

​
Unauthorized

Returned when the JWT is missing, expired, or was issued for a different user type (e.g. a storefront token on an admin endpoint), or when a customer’s email has not been verified. 
{
  "error": "Unauthorized"
}
HTTP status: 401 Unauthorized

​
Maintenance mode

Returned when the vista_mantenimiento home view has state = 1. All endpoints that check maintenance status return this response. 
{
  "message": "El sitio está en mantenimiento"
}
HTTP status: 503 Service Unavailable

​
HTTP status codes used

HTTP StatusMeaningWhen returned
200 OKSuccessAll successful responses, including business-logic errors that use "message": 403 inside a 200 body
201 CreatedResource createdPOST /api/auth/register (user registration only)
400 Bad RequestValidation failureRequest input fails Laravel Validator rules
401 UnauthorizedAuthentication failureMissing, expired, or invalid JWT; unverified email on storefront login
403 ForbiddenPassword mismatchPOST /api/ecommerce/profile_client when current_password is wrong (AuthController::update). The 403 code also appears inside JSON bodies as an application-level signal on HTTP 200 responses everywhere else.
429 Too Many RequestsRate limit exceededCaller has exceeded the throttle middleware limit for the current 1-minute window
503 Service UnavailableMaintenance modevista_mantenimiento home view is active

Build docs developers (and LLMs) love

Get started for freeTalk to us