Selldone CLI

🛍️ Go to the Full Storefront Project ▶

⚡ Update Selldone CLI everytime you start using it! We have been updating it frequently every day.

npm update -g selldone-cli

Introduction

Welcome to the documentation for selldone cli, a command-line tool designed for seamless deployment of custom storefront layouts for Selldone users. Selldone, accessible at Selldone.com, is a comprehensive e-commerce platform that empowers businesses and individual entrepreneurs to create, manage, and grow their online presence effortlessly.

What is Selldone?

Selldone is an innovative e-commerce solution that offers a wide range of features to facilitate online store management, sales, marketing, and much more. It provides a user-friendly interface and powerful tools to create a unique and efficient online shopping experience.

What is a Layout?

In the context of Selldone, a Layout refers to a custom storefront design. It allows users to personalize their online shop's appearance and functionality, creating a unique brand experience for their customers. To get started with a fully customizable storefront project, 🛍️ Go to the Full Storefront Project ▶.

Using Selldone CLI

Selldone CLI is an essential tool for developers looking to integrate their custom Layouts into the Selldone platform. This tool facilitates the process of building, packaging, and deploying your storefront designs onto the Selldone platform.

Prerequisites

Before using Selldone CLI, ensure that you have Node.js installed on your system. The tool is designed to run on Node.js and requires a basic understanding of JavaScript and command-line operations.

Installation

npm install -g selldone-cli

or install locally: npm install selldone-cli --save-dev or yarn add selldone-cli --dev

Local installation (Dev mode)

npm uninstall -g selldone-cli
npm install -g .

Usage

To run selldone, navigate to the directory containing your Vue project and execute it:

selldone

Success deploy message

The script will guide you through the process of deploying your custom Layout. Follow the prompts to authenticate, build, and upload your project to Selldone.

After deployment, view and manage your Layouts in the Selldone Layouts dashboard.

Features

• Authentication: Securely log in to your Selldone account via OAuth2.
• Build and Zip: Automatically build your project and package it into a zip file.
• Upload: Seamlessly upload your zip file to the Selldone platform.
• Version Control: Ensure that each version of your Layout is unique and properly managed.

AI Agent Skills

For AI coding agents: read package-selldone-storefront-layout before building or packaging a storefront Layout. It defines the required build/ZIP structure and includes validation and packaging tools.

Layout deployment API

The CLI checks that the requested version is available before uploading the built Layout. Both requests include Authorization: Bearer <access_token> and Accept: application/json.

Action	Endpoint	Content type	Required backend scope
Check version	POST https://api.selldone.com/developer/layouts/check-version	application/json	SCOPE_SELLDONE_DEVELOPER_READ
Upload deployment	POST https://api.selldone.com/developer/layouts/deploy	multipart/form-data	SCOPE_SELLDONE_DEVELOPER_WRITE

1. Check version

The request body contains:

Field	Type	Validation
package	string	Required; 12–64 characters; must match ^[A-Za-z0-9.-]+$
version	string	Required; 1–64 characters; must match ^[A-Za-z0-9.-]+$

{
  "package": "com.example.layout",
  "version": "1.0.0"
}

When the version is available, the HTTP 200 response is:

{
  "success": true,
  "version": "1.0.0",
  "layout": null
}

layout contains the existing Layout object when the package already exists, or null for a new package. A duplicate version returns an application-level error response:

{
  "error": true,
  "error_msg": "Version is duplicated! Please change the version in the 'manifest.json' and try again.",
  "layout": {}
}

The shown API implementation also returns the duplicate result with HTTP 200; consumers must therefore check success or error in the response body. Invalid parameters return HTTP 422 validation errors.

2. Upload deployment

The upload request is multipart/form-data. Let the HTTP client generate the multipart boundary.

Part	Type	Validation
manifest	text containing JSON	Required and must contain valid JSON
file	ZIP file	Required; ZIP MIME type; maximum 51,200 KiB (50 MiB); must pass the ClamAV scan

The decoded manifest JSON uses this schema:

Field	Type	Validation
package	string	Required; 12–64 characters; must match ^[A-Za-z0-9._-]+$
version	string	Required; 1–64 characters; must match ^[A-Za-z0-9._-]+$
name	string	Required; 8–255 characters
description	string or null	Optional; include it as null when there is no description
storefront	boolean	Required
backoffice	boolean	Required

{
  "package": "com.example.layout",
  "version": "1.0.0",
  "name": "Example Layout",
  "description": null,
  "storefront": true,
  "backoffice": false
}

For compatibility with the complete CLI flow, use lowercase letters, digits, dots, and hyphens in package and version. Although the upload validator accepts underscores, the version-check endpoint does not. The current CLI also requires at least one of storefront or backoffice to be true.

A successful upload returns HTTP 200:

{
  "success": true,
  "message": "Layout uploaded successfully!",
  "layout": {},
  "deploy": {
    "layout_id": 123
  }
}

layout and deploy are the serialized server-side model objects; their complete field sets may evolve. The CLI uses deploy.layout_id to print the Layout management URL. Before returning, the server creates or reuses the Layout, creates a new deployment, and sets the deployment version as layout.version_beta. Invalid multipart fields or manifest content return HTTP 422 validation errors. Decoded-manifest errors are returned as a field-keyed JSON error bag; the application's standard validation envelope is used for invalid top-level multipart fields.

Related shop Layout route

POST /shops/{shop_id}/layout is routed to ShopLayoutController::api_setShopLayout, with shop_id as a path parameter. It is not called by the current CLI. The route declaration alone does not define its authorization scope, request body, response schema, or API host, so those details are intentionally not inferred here.

Publish Package

URL: https://www.npmjs.com/package/selldone-cli

npm publish

Contributing

Contributions to Selldone CLI are welcome! If you have suggestions, improvements, or bug fixes, feel free to fork the repository, make changes, and submit a pull request.

License

This project is licensed under the MIT License - see the LICENSE file for details.

---

Enjoy building and deploying your custom storefronts with Selldone!

---

For more information about customizing your Selldone storefront, visit the Full Storefront Project.

Happy coding! 🎊

Authentication flow

Running selldone and choosing Login, or deploying without a saved token, starts the following OAuth2 flow:

Step	Request	Input	Output used by the CLI
1. Browser login	GET https://selldone.com/developers/login?state=<state>	state: a random, URL-safe 64-character value generated by the CLI	Redirect to http://localhost:3777/callback?code=<authorization_code>
2. Token exchange	POST https://selldone.com/oauth/token	JSON: { "grant_type": "authorization_code", "client_id": 6663, "redirect_uri": "http://localhost:3777/callback", "code": "<authorization_code>", "code_verifier": "<state>" }	{ "access_token": "..." } (other fields are ignored)
3. 2FA status	GET https://api.selldone.com/security/2fa/check	Authorization: Bearer <access_token>	JSON containing has_2fa and, when authentication is complete, user
4. 2FA verification (when required)	POST https://api.selldone.com/auth/2fa	Bearer token plus JSON: { "code": "<6-digit-code>" }	{ "success": true, "user": { ... } } on success

The CLI listens on http://localhost:3777/callback during login. If the 2FA status response already contains user, login completes immediately. Otherwise, the CLI asks for a six-digit numeric 2FA code and verifies it; the access token is persisted only after that verification succeeds. The token is stored in ~/.selldone-dev/.persist (or .persist-debug in debug mode), and Logout clears it. If the 2FA status check fails, the saved token is cleared and the browser login flow starts again.