Developer User Guide

Introduction

The Component Marketplace Developer Console is a management dashboard specifically designed for component marketplace developers/sellers (hereafter referred to as "developers"). Developers can log in to this platform by scanning a QR code via the Luffa mobile app. Once logged in, developers can manage components, view data analytics, and access various operational reports.​

Currently, the console supports the following operations and reporting features：​

• Component Publishing: Publish components by completing required fields and uploading the component package, API documentation, cover image, and detail images.

• Component Status Management: Manage the status of components, including updating component information, submitting for review, publishing/unpublishing, and releasing new versions.

• Account Fund Operations: Claim earnings from component subscriptions, and interact with smart contracts to stake or redeem EDS tokens.​

• Financial Data Overview: Access financial data related to your account, including recent and historical income, order trends, reward distributions, and detailed breakdowns.​

• Top-Selling Products Analysis: View rankings and detailed metrics of top-performing components under your account.​

• Component Information Overview: Access key information for all components under your account, including basic attributes, sales volume, revenue data, dividend distributions, and real-time status.​

• Order Data Overview: Review order details for all components, including subscription duration, payment information, on-chain transaction data, and subscriber identities.​

• Staking Details Overview: View staking-related details under your account, including total staked amount, redeemable stake, and locked stake.​

Prerequisites

Before using the Component Marketplace Developer Console, please ensure the following prerequisites are met:

• Mobile App Registration/Login: Register or log in to your account via the Luffa mobile app (Android/iOS).​

• Wallet Balance Check: Ensure the primary wallet associated with the logged-in account has a balance greater than zero.​

• Client Version Requirement: Verify that the Luffa mobile app version is xx.xx.xx or higher. Older versions do not support QR code signature functionality.​

Additional Notes

The Component Marketplace Developer Console includes a number of default rules and system configurations. Familiarizing yourself with these details will help ensure a smoother user experience:

• QR Code Expiration: All QR codes generated within the marketplace are valid for 5 minutes. Please complete the scanning and confirmation process within this time frame. If the code expires, click the refresh icon or reload the page to generate a new QR code.​

• Account Consistency for QR Code Actions: Except for login, all QR code confirmations within the system require that the scanning account matches the developer account currently logged in (i.e., the same wallet address). Any mismatch will result in a failed signature attempt.​

1.Login and Registration

This section provides a step-by-step guide—with illustrations—on how to access and log in to the Developer Console.

Before using any features, please note the official login URL for the Developer Console: https://component-store-test.endless.link/seller

1.1 Direct Access via URL​

When accessing the developer portal via the specified URL, you will be directed to the QR code login interface (as shown in the illustration). The login QR code is time-sensitive and must be scanned and confirmed before the countdown expires; otherwise, the code will become invalid and a timeout message will be displayed. If the QR code expires, you can simply click the refresh button at the bottom of the page or reload the entire page to generate a new valid code. To complete the login process, use the Luffa mobile app to scan the active QR code and confirm the login within the app.​

Please note that the developer portal does not have a separate registration process. Once you scan the QR code and confirm login through the mobile app, the system will automatically register and log you in—streamlining the workflow and improving overall user efficiency.

1.2 Redirect via the Component Marketplace​

If you access this page by clicking the “Developer Portal” button on the Component Marketplace and have already logged in by scanning the QR code on the marketplace page, the QR code login interface described above will not appear. Instead, you will be redirected directly to the developer management dashboard, where you can immediately begin managing components, viewing data, and performing other related operations.

2. Becoming a Developer

After logging in via QR code, the system will verify your user role before granting access to the management dashboard. If you have not yet registered as a developer, you will be directed to a "Become a Developer" onboarding page.

Tip: To unlock developer access, standard users are required to stake a certain amount of EDS tokens in the Component Marketplace. Only after this requirement is met will users be able to upload and manage components.

To proceed, scan the QR code displayed at the center of the “Become a Developer” page using the Luffa App, and complete the payment and confirmation process in the app.

Before initiating this step, ensure that your main wallet in the Luffa App has a positive EDS balance. Otherwise, a valid QR code cannot be generated.

If an error occurs during QR code generation, follow the corresponding error message instructions:

• If prompted with “Insufficient balance”, please top up your EDS wallet immediately;

• If you encounter issues that cannot be resolved on your own, please contact official support for technical assistance.

Once the QR code is scanned and the confirmation is completed, the system will display a Payment Confirmation Waiting Screen.

Tip: This process typically takes 3–5 seconds. Please wait patiently while the system processes the request.

After a brief moment, the system will notify you of the result of your Developer Activation.

If you encounter any issues during this process, please contact official support for assistance.

3. Developer Console

After successfully logging in to the developer portal and completing the “Become a Developer” verification, users will be redirected to the Developer Console Home. This dashboard provides a comprehensive overview of key account data, including:

• Basic Account Information: Such as account name and verification status;

• Data Analytics Module: Displays key business metrics including total orders, revenue, and user traffic;

• Quick Access Shortcuts: Direct links to essential functions like product management, order processing, and fund settlement;

• System Notifications: Updates on platform announcements, transaction alerts, and verification status.

This data overview allows developers to quickly assess operational performance and efficiently manage their offerings.

3.1 Account Data Overview

The first section of the dashboard provides real-time metrics on core business performance, including:

• Today's Revenue & Growth Rate: Displays current day’s income along with percentage change compared to the previous day;

• Today's Completed Orders & Growth Rate: Shows the total number of successfully processed orders and the increase or decrease from the day before;

• Today's Component Invocations & Growth Rate: Indicates the number of times all components were called today, along with the trend compared to the previous day;

• Today's Invocation Success Rate & Growth Rate: Displays the success rate of component calls and changes in success percentage compared to the previous day.

3.2 Financial Data Overview

The left side of the second section presents a 30-day revenue trend line chart by default, helping developers visualize income patterns. The time range and data views are customizable via the following tools:

• Time Range Selection: Filter data by day, week, month, or custom date range;

• Metric View Switching: Toggle between total revenue, average order value, and other dimensions;

• Trend Analysis Tools: Enable comparison tools and peak markers to help identify fluctuations or anomalies in revenue.

The right side of the same section highlights key financial indicators:

• Total Account Revenue: Displays cumulative settled earnings (net of platform service fees)；

• Today's Revenue Growth Rate: Shows day-over-day change in revenue, e.g., “+15%” or “-8%”.

3.3 Top-Selling Components Leaderboard

The third section features a sortable sales leaderboard for all published components, ranked by total sales volume. The table includes the following fields:

3.4 Personal Center

Click your user avatar in the top-right corner to open the Personal Center modal. From here, you can:

• View account basics (e.g., verification status, registration date);

• Edit personal profile (e.g., avatar, contact information);

• Access account security settings (e.g., change password, bind phone number);

• View historical activity logs and platform notifications.

3.5 Personal Center – Operational Guide

• Click “Personal Center” to open the full account settings page;

• Click “Logout” to securely sign out of your current session.

3.6 Personal Center – Details Page

The detailed account page displays current user information, including:

Displayed Fields:

• Avatar (default or custom uploaded image);

• Username (set during registration);

• Wallet Address (unique address linked to your account);

• Luffa Friend Link (a shareable link for others to add you as a contact).

Editable Fields: Only the “Luffa Friend Link” is editable. To update:

1. Enter your new link content in the input field under “Link Social Account.”；

2. Click the “Save” button to apply changes. The updated link will take effect immediately.

4. Component Publishing

4.1 Publishing a Component

Developers can submit their own components through the Component Publishing page by filling out four main categories of information. Fields marked with “*” are mandatory and must be completed before submission.

4.2 Component Type

• Type Selection: Choose the appropriate component category. Each type has different requirements and publishing rules.

• Currently Supported: Only Basic Components are supported at this stage. Additional categories such as Advanced Functional Componentsand Industry-Specific Components will be introduced in future updates.

4.3 Basic Component Information

You are required to fill in the basic attributes of the component in this section. The specific field requirements are as follows:

Field Input Guidelines

Component Name (Required):

• Must start with a letter or number. May include letters, numbers, underscores (_), or hyphens (-);

• Must be unique; duplicate names with existing components are not allowed.

Component Version (Required):

• Must start with a number (e.g., "1.0", "2.3.5");

• Allowed characters: digits and periods (.). Format must follow the semantic versioning convention: major.minor[.patch].

Component Category (Multi-select):

• Select tags based on functionality or industry (e.g., “Data Visualization,” “AI Tools”).

Component Cover Image (Required):

• Accepted formats: JPG, PNG, GIF;

• Recommended dimensions: at least 800×400 pixels; File size must not exceed 5MB.

4.4.Component Details

You must complete the core information and resources for the component in this section. The specific submission requirements are as follows:

Field Input Guidelines

Binary File or Component Service Address (Required, choose one)：

• Binary File: Must be in ELF format, size limited to 40MiB.

• Service Address: Should follow the format <ip>:<port>.

API Documentation (Required)：

• Accepted formats: Markdown (.md) or PDF. File size must not exceed 50MiB.

Component Media (Optional):

• Images (PNG or JPG format); Videos (Common formats such as MP4, MOV, AVI);

• Maximum file size per video: 200MiB. Multiple files can be uploaded to aid in showcasing the component.

Component Description (Required):

• Supports rich text (text, images, links, etc.)；

• Recommended content includes feature descriptions, usage instructions, and FAQs.

4.5 Pricing Information

You are required to configure the pricing plan for your component in this section. The specific rules and operational guidelines are as follows:

Pricing Strategy Configuration

• Default Pricing Templates: Three predefined tiers: Basic / Standard / Professional. Pricing is based on both usage duration (default: 1 month) and invocation quota.

• Custom Pricing Options:

1)The system uses predefined pricing parameters by default (e.g., the Standard tier is set to 0.000099 EDS per month, including 10,000 invocations)；

2)You can directly modify the input field to set a custom price, with a minimum precision of 0.00000001 EDS;

3)The number of invocations and corresponding pricing should align with the business use case. Flexible tier customization is supported, such as adding an “Enterprise” plan or segmenting pricing based on functional modules.

Example: Default Pricing for the Standard Tier

Operational Notes

• All pricing is based on a calendar month cycle; upon expiration, services will either auto-renew or terminate depending on user settings；

• After setting prices, you must click “Save” for changes to take effect. Unsaved changes will be lost if the page is refreshed；

• To adjust historical pricing, navigate to the “Published Components” list and select the relevant component to reconfigure its pricing strategy.

4.6 Component Publishing Operation

Once all required fields have been completed, click the “Launch” button to submit your component for publication. The detailed process is as follows:

4.7 Publishing Workflow

1. Submit for Review: After verifying that all mandatory fields (marked with “*”) are properly filled out, click the “Launch” button to trigger system validation;

2. Field Validation: The system will automatically check for correct input formats, such as name uniqueness, file type and size, and pricing precision;

3. Result Feedback：

• If all fields meet the requirements, a “Publish Successful” message will appear, and the component will enter the platform’s review process (typically completed within 1–3 business days);

• If validation fails, the system will highlight the erroneous fields and provide reasons (e.g., “Unsupported file format,” “Invalid price precision”). You must make the necessary corrections and resubmit.

4.8 Post-Publication Status Tracking

• You can view the status of your submitted components in the “My Components” list. Status indicators include “Under Review,” “Published,” and “Rejected.”;

• If the status is “Rejected,” click “View Details” to see the reason for rejection. Make the necessary revisions and resubmit the component for publication;

• Click “Continue Publishing” to return to the publishing page and continue editing

• Click “View Products” to view detailed information about your published components

5. Component Modification

5.1 Accessing the Component Details Page

Access Methods:

• Click the “View” button in the Component Management page；

• Click the “View Products” button after successfully publishing a component.

Users can click the “Edit” button to enter the component editing page. Only components with the status “Uploaded” or “Audit Failed” are eligible for editing.

5.2 Component Editing Workflow

Accessing the Edit Page

• To enter the editing interface, click the “Edit” button on the component details page, or select the corresponding component from the Component Management list and click “Modify.”

Field Editing Rules

• Auto-Fill Mechanism: The system will automatically populate all fields with the component’s existing information. Users only need to update the desired content;

• Editable Fields Include:

1. Basic Attributes: Component name, version number, category, cover image, etc;

2. Detail Content: Binary file, API documentation, media assets (images/videos), and rich text description;

3. Pricing Strategy: Invocation limits, pricing parameters, and service duration for each tier (default is 1 month).

• Editing Standards: All modified values must comply with the original Component Publishing field format requirements (e.g., file type and size, pricing precision, etc.).

Submission and Update Process

1. After completing the necessary changes, click the “Launch” button to submit your updates.；

2. The system will automatically validate the modified fields using the same rules as the initial publishing process；

3. If validation passes, a “Modification Successful” message will appear and the updated component information will be reflected in real time. (If the update involves binary files or pricing changes, the component must undergo platform re-review, which will be completed within 1–3 business days.)

Notes

• If the modification involves core functionality changes (such as replacing the binary file or updating API endpoints), it is strongly recommended to update the API documentation and usage instructions accordingly;

• Pricing Update Logic:

1. Existing Users: The original pricing will remain effective until the end of the current service period;

2. New Users: The updated pricing will take effect immediately upon publication;

• Components that are currently under review cannot be edited. Please wait until the status is updated to either “Published” or “Audit Failed” before making further changes.

6. Component Management

Users can manage all components under their account via the Component Management page. Components in different statuses support different types of operations.

The following section provides a detailed explanation of component management functionality.

6.1 Search and Filter

This section outlines all currently supported filtering options and operational methods available within the component list view.

6.2 Default Display

By default, the system displays all components (excluding deleted ones) under the account in reverse chronological order based on creation time.

The columns displayed from left to right in the component list include:

• Component Name

• Component Category

• Component Tags

• Creation Date

• Current Status

• Component Pricing Information

• Component Actions

6.3 Status Filter

Users can filter components by status by clicking the corresponding status labels at the top of the display area. The number in parentheses next to each label indicates the count of components in that particular status.

6.4 Keyword Search

Users can perform fuzzy searches by entering keywords.

Currently, the search functionality supports matching against the Component Name and Component Details fields.

6.5 Date Range Filter

Users can narrow down the list by specifying a date range to view components created within a selected timeframe.

6.6 Category Filter

Users can filter components by component category to view only components that belong to a specific functional or industry group.

6.7 Pagination Controls

Users can quickly switch between pages in the component list using the pagination controls, either by clicking Next/Previous or selecting a specific page number.

7. Component Operations

Before managing components, it's important to understand the full range of component statuses and their lifecycle within the system.

In the developer console, component status transitions follow the flow described below.

1. Component Lifecycle

When a component is first created, its initial status is Uploaded. After submission for review, if the component fails the administrator review, its status changes to Review Failed.

In this state, the reason for rejection can be viewed in the timeline section on the right side of the component details page.

Components in the Review Failed state support the following actions:

Available Operations (left to right):

• Submits the component to the administrator for review. If approved, the component will be deployed, and the status will update to Available. If rejected, the component status returns to Review Failed, along with the rejection reason.

• Delete Component: Permanently deletes the uploaded component. Once deleted, the component will no longer appear in the list and this action cannot be undone.

• Edit Component: If the user needs to modify an uploaded component or make adjustments after a failed review, this feature can be used to edit and update the component accordingly.

• View Component: Opens the component details page.

UnderReview

When a user submits a component for administrator review, its status will be updated to Under Review. In this state, the component only supports view-only access and cannot be edited or modified.

Available

Once the component is successfully deployed, its status will be updated to Available. At this stage, the component is officially listed on the marketplace and can be purchased or subscribed to by users.

The operations corresponding to the action buttons from left to right are as follows:

• Unpublish Component: This action removes the component from the marketplace, making it unavailable for user discovery or subscription. Once successfully unpublished, the component’s status will be updated to Removed.

• Update Component: Upload a new version of the component package along with release notes and a version number to complete the version update process.

• View Component: Click this button to access the component’s detail page.

Removed

Once a component is successfully unpublished, its status will be updated to Removed. At this point, the component will no longer be discoverable in the marketplace and cannot be purchased or subscribed to by users.

The operations corresponding to the action buttons from left to right are as follows:

• Republish Component: This action relists the component on the marketplace. Once successfully republished, the component status will be updated to Available.

• View Component: Click this button to access the component’s detail page.

8. Component Order Management

Users can view and filter all component-related orders under their account through the “Order” module in the developer console.

8.1 Search and Filter

Default Display

By default, the system displays a list of all non-deleted orders associated with the user's components, sorted in reverse chronological order based on component creation time. The columns in the order list, from left to right, are defined as follows:

• Transaction Hash: If the order was successfully completed, this field displays the corresponding on-chain transaction hash.

• Component Name

• Component Category

• The payment address for this order

• Order Status

• Order Creation Time

• Transaction Time

• The total amount spent on the order

• Action: View detailed order information

8.2 Order Status Filter

Users can filter the order list by clicking on the status labels located at the top of the display panel. The number in parentheses next to each status indicates how many orders fall under that specific status.

8.3 Order Search

Users can perform both fuzzy and exact searches using keywords.

• Fuzzy Search Scope: Component names included in the orders

• Exact Search Scope: Transaction hash and consumer wallet address associated with the order

  

8.4 Order Date Range Filter

Users can filter orders based on a specified date range to view those created within a selected timeframe.

8.5 Order Pagination

Users can navigate between different pages of the order list by clicking the pagination buttons or selecting a specific page number, enabling quick access to orders on the desired page.

8.6 Order Details

Click the “Check” button in the order list to open the Order Details page.

The Order Details page displays comprehensive information about the selected order, as illustrated in the example below:

The Order Details page is divided into three main sections:

8.7 Basic Order Information

The Basic Information section displays the following fields from top to bottom:

• The hash of the payment transaction

• Current Order Status: The current status of the order (available statuses include: Pending, Expired, Canceled, and Completed)

• Payment Time

• The total payment amount for the order

• Consumer Nickname

• Consumer Wallet Address

8.8 Order Status Flow

The Order Status Flow section presents a visual timeline of the order lifecycle, including key timestamps such as order creation time, payment time, and transaction confirmation time.

8.9 Product Information in the Order

This section displays the list of products included in the order, detailing the basic information for each item along with a summary of pricing. For each product entry, the fields from left to right are as follows:

• Component Name

• Component Type

• Component Price

• Purchased Usage Duration

• Quantity Purchased

• Total Price for This Item

9. Component Finance Page

The Component Finance page provides an overview of the user’s earnings, including income details, distribution and withdrawal records, and staking information.

9.1 Income Details

This section displays earnings data generated by all components under the current user account, presented across three key metrics:

• Receivable income: Displays the amount of income currently available for withdrawal. (Developer earnings are released linearly over time following a user’s purchase of a component, so this amount increases gradually until fully unlocked.)

• Total revenue: Shows the total accumulated earnings of the user, including withdrawn income, released income, and unreleased income.

• Cumulative withdrawal: Indicates the total amount of income that has already been withdrawn by the user.

This section also includes a “Withdraw” button. Clicking this button will generate a QR code for claiming released income. By scanning the code using the Luffa App (logged into the current user’s account), the developer can confirm and receive the available earnings.

Since income is released on a per-second basis, the actual amount received may be slightly higher than the amount displayed on the UI at the time of withdrawal.

9.2 Staking Information

This section displays the user's current staking activity within the Component Marketplace and provides two primary actions: “Pledge” to initiate a new stake, and “UnPledge” to redeem available staked assets.

There are three main staking scenarios supported by the marketplace: User Trial Staking, Developer Staking, Standard Staking. User Trial Staking: In accordance with component trial rules, users must stake a certain amount of EDS tokens to access trial components. These tokens are locked for the duration of the trial. Once the trial ends, users can redeem their staked EDS at any time. Developer Staking: To publish components in the marketplace, users must first become developers by staking a required amount of EDS. These tokens will be locked for one year. If the developer's services run smoothly through the end of the service period, the staked EDS can be redeemed after the one-year lock period. Standard Staking: Users may also voluntarily stake EDS into the platform. This type of staking is unlocked by default, and staked tokens can be redeemed at any time.

Staking: The amount displayed below the “Staking” label represents the total staked amount, including both locked and unlocked tokens.

Pledge：Users can utilize the “Pledge” feature to initiate a standard staking operation. Tokens staked through this method are not subject to lock-up and can be redeemed at any time. Upon clicking the “Pledge” button, an input field will appear prompting the user to enter the desired staking amount, as shown in the example below: Enter the amount you wish to stake in the input field (only whole numbers are currently supported), then click “Staking” to generate a staking QR code.

Scan the QR code using the Luffa App logged into your account to confirm and complete the staking operation.

UnPledge

Users can use the “UnPledge” feature to redeem their staked tokens. Only unlocked tokens are eligible for redemption; locked tokens can be redeemed only after the lock-up period has expired. Upon clicking the “UnPledge” button, an input field will appear for entering the amount to be redeemed, as shown in the example below: Enter the amount you wish to redeem in the input field (only whole numbers are currently supported), then click “UnStaking” to generate a redemption QR code. Scan the QR code using the Luffa App logged into your account to confirm and complete the redemption process.

10. Revenue Distribution and Withdrawal Details

This module displays detailed records of revenue allocated to the developer when their components are subscribed to, as well as the developer's corresponding withdrawal history.

10.1 Revenue Distribution Details

The Revenue Details section logs each instance of profit-sharing allocated to the developer from subscribed components.

In the example above, the fields from left to right are as follows:

• Distribution Time: The timestamp when revenue was calculated for the subscribed component.

• Component Name: The name of the subscribed component.

• Distributed Amount: The amount of revenue allocated to the developer from the subscription.

• Status: The current status of the distribution record

• Order ID: The ID of the order associated with the subscribed component.

• Transaction Hash: The on-chain transaction hash corresponding to the subscription payment.

10.2 Withdrawal Records

The Withdrawal Records section logs every instance in which the developer has claimed distributed revenue.

In the example above, the fields from left to right are as follows:

• Withdrawal Time: The timestamp when the developer withdrew earnings

• Withdrawal Amount: The amount of revenue withdrawn by the developer

• Withdrawal Transaction Hash: The on-chain transaction hash associated with the withdrawal

8.3 Filtering Options

Both the Revenue Details and Withdrawal Records sections support keyword search and date range filtering

·Search

For Revenue Details, users can perform fuzzy searches based on component name, transaction hash, and subscriber address. For Withdrawal Records, users can perform fuzzy searches based on the withdrawal amount.

·Date Range Filtering

Both sections follow the same rule: selecting a specific date range will return all revenue or withdrawal records that occurred within the selected period.

11. How to Develop in the Component Marketplace

This tutorial will guide you through the process of developing, packaging, and accessing your service within the Component Marketplace.

Introduction

Currently, the Component Marketplace supports only binary packages in ELF format.

Your First Component

In this example, we will create a simple HTTP service that exposes a /ping endpoint, which will be used to test and verify service connectivity. The example will be implemented using the Go programming language.

Step 1: Write an HTTP Service

Create a new project named MyFirstComponent, and within the project’s root directory, create a file called main.go. Using Go’s built-in net/http package, set up a web server and expose an endpoint named /ping. The complete file content is as follows:

package main

import (

"fmt"

"log"

"net/http"

"os"

"time"

)

func main() {

addr := os.Getenv("HTTP_ADDRESS")

if addr == "" {

addr = ":8080"

}

http.HandleFunc("/ping", func(w http.ResponseWriter, r *http.Request) {

if r.Method != http.MethodGet {

w.WriteHeader(http.StatusMethodNotAllowed)

fmt.Fprintf(w, "Method not allowed")

return

}

w.WriteHeader(http.StatusOK)

w.Write([]byte("pong"))

})

server := &http.Server{

Addr: addr,

ReadTimeout: 5 * time.Second,

WriteTimeout: 10 * time.Second,

IdleTimeout: 15 * time.Second,

}

fmt.Printf("Server starting on %s \n", addr)

if err := server.ListenAndServe(); err != nil {

log.Fatalf("Server failed to start: %v", err)

}

}

As shown in the code above, we use Go’s native net/http library to create a web server and expose a /ping endpoint. Once the service is successfully deployed, users who access this endpoint will receive a "pong" string in response.

Step2: Package

Navigate to your program directory and execute the following build commands:

export GOOS=linux

export GOARCH=amd64

go build -o pingDemo ./main.go

After a successful build, a binary file named pingDemo will be generated.

Step3: Upload Component Information

Access the developer portal: https://component-store-test.endless.link/seller After logging in and registering as a developer, go to the Publish page in the developer console. Fill out the required fields as instructed on the page, upload your component, and submit it for publication. After successfully publishing the component, navigate to the component list and submit a request for review and deployment. Wait for the administrator to complete the review and deployment. If the deployment is successful, the component status will be updated to “Available.”

Step4: Test Component Purchase and Access the Service

Once the component status is “Available”, it becomes searchable and purchasable in the Component Marketplace. At this stage, switch to the buyer portal: https://component-store-test.endless.link/buyer

Locate the component you just deployed and purchase a one-month subscription. After completing the purchase, navigate to the My Components section in your personal dashboard, locate the component you just purchased, and generate the API key required for accessing the service.

Step 5: Access the Deployed Component

Once all previous steps have been successfully completed, you will have the following information:

• Deployed Component Name: MyFirstComponent

• Purchased Component API Key: e8ac49bf1d120048

To access the component service, simply construct the access URL as described below:

After deployment, the Component Marketplace automatically handles data forwarding, so users do not need to specify the predefined port of the service.

Component Access URL Format: https://component-store-test.endless.link/<componentName>/<apiKey>

Using the example above, the correct request URL would be:

https://component-store-test.endless.link/MyFirstComponent/e8ac49bf1d120048/ping

Use your preferred tool to send a request to this URL. As shown in the illustration, a successful response will return "pong", completing the full component deployment and access workflow.