LingXing ERP connector (领星 ERP): ask about Amazon orders, FBA stock and profit in plain language
This page is for operations leads and IT staff at cross-border sellers who run LingXing ERP (领星 ERP) and want staff to query it through OrgRelay. It covers the twelve tools, the AppID, AppSecret and IP whitelist set-up, how tokens and request signing are handled, and what happens when someone asks the AI to create a purchase order.
What staff can ask
LingXing holds marketplace data that operations, purchasing and finance all need. Questions usually start from a shop, because most LingXing APIs are keyed by the shop ID (sid):
- "我们在领星里绑了哪些店铺?" ("Which shops are linked in LingXing?") calls
orders.shops. It returns eachsid, shop name, marketplace and status, which the AI then reuses. - "How many units of EU-FDH-843-22 are sellable in FBA right now, and how many are inbound?" calls
inventory.fbawithsidandsku. It returns available, inbound and reserved quantities. - "上个月德国站利润最高的 10 个 MSKU 是哪些?" ("Which ten MSKUs made the most profit on the German store last month?") calls
finance.profitwith the month and the German shop'ssid. It returns sales, units, fees and profit per MSKU. - "What did SP campaigns spend yesterday on the UK shop, and at what ACoS?" calls
ads.reportwithsidandreport_dateset to yesterday. LingXing builds this report one day at a time, so a weekly view means seven calls. - "给供应商 218 下一张采购单,SKU A-1001 共 600 件,入 3 号仓。" ("Raise a PO to supplier 218 for 600 of A-1001 into warehouse 3.") calls
purchase.create. The AI first asks for the unit price, because every line needs one, then the request waits for approval.
Tools
| Tool | Access | What it does | Key parameters |
|---|---|---|---|
orders.shops |
read | Lists Amazon shops (sid, name, marketplace, status) |
none |
orders.search |
read | Amazon orders for a date range, optionally per shop | date_from, date_to (required), sid |
orders.get |
read | Order detail by Amazon order ID | order_no, required |
inventory.fba |
read | FBA stock: available, inbound, reserved, with ASIN and FNSKU | sid (required), sku |
inventory.list |
read | Local and overseas warehouse stock (本地仓 / 海外仓) | sku, warehouse_id |
products.search |
read | Local product (SKU) list with category and status | sku |
products.listings |
read | Amazon listings: MSKU, ASIN, title, price, status, FBA available | sid (required), keyword (MSKU) |
finance.profit |
read | Profit report by MSKU: sales, units, fees, profit | date_from, date_to (required), sid |
purchase.search |
read | Purchase orders with supplier, status, total and expected arrival; last 30 days when no dates are given | date_from, date_to, status |
logistics.shipments |
read | FBA inbound shipments (头程发货单) with carrier and tracking number | date_from, date_to |
ads.report |
read | Sponsored Products campaign report for one day: spend, impressions, clicks, orders, sales, ACoS | sid, report_date (both required) |
purchase.create |
write · approval | Creates a purchase order awaiting delivery | supplier_id, warehouse_id, lines of {sku, qty, price} (price required), purchaser_id, remark |
List tools take limit (default 20, at most 100) and cursor. They are sent to LingXing as offset and length. The next cursor is the new offset while LingXing's total says more rows remain. The output follows OrgRelay's standard tools, so an order from LingXing and one read directly from Amazon SP-API carry the same field names.
Credentials and scopes
Two fields are required, one is needed only for purchase orders, and one is advanced:
- AppID and AppSecret. The AppSecret is stored encrypted and shown afterwards only by its last four characters, as described in security.
- LingXing user ID for purchase orders (optional): a LingXing user ID that
purchase.createsends as the operator (opt_uid) and as the default purchaser. You can look it up under 设置 → 账号管理 (account management). Leave it empty if the AI should never create purchase orders. - API base URL (advanced), default
https://openapi.lingxing.com.
LingXing's guide to AppID and IP whitelist configuration is direct about two points. The AppID and AppSecret can access all of the company's data. Resetting the AppSecret invalidates the old one immediately. There are no per-API scopes that you choose. Access is the whole company, minus any API LingXing has not enabled for you (error 2001004).
What OrgRelay does with those two values, following LingXing's API access guide:
- Token. It posts
appIdandappSecretas multipart form data to/api/auth-server/oauth/access-token. The access token lasts about two hours (expires_in7199 seconds). - Renewal. About a minute before expiry, it calls
/api/auth-server/oauth/refreshwith the refresh token. LingXing allows each refresh token to be used once and keeps it valid for two hours, so the connector always stores the latest one. If renewal fails, it simply requests a new token with the AppSecret. Errors 2001003 and 2001005 trigger one fresh token and a single retry. - Signing. Every business call is signed. All parameters plus
access_token,app_keyandtimestampare sorted by ASCII and joined askey=value&…, with empty values skipped. The result is hashed with MD5, upper-cased, AES-128-ECB encrypted with the AppID as the key, Base64 encoded and URL encoded. A signature is valid for two minutes, so the Mac mini's clock must be accurate. Error 2001007 points at clock drift. - Transport. The token travels in an
Authorization: Bearerheader, andapp_key,timestampandsigngo in the query string. That matches LingXing's rule from 1 January 2027, whenaccess_tokenin the URL query stops being accepted. The SP campaign report call also sendsX-API-VERSION: 2, which makes LingXing readoffsetas a row offset starting at 0.
Do not run another integration with the same AppID that requests fresh tokens independently. LingXing's FAQ notes that repeated token requests from elsewhere make tokens change, which shows up as error 2001005. The auth overview describes how OrgRelay handles this kind of signed-token platform.
Which actions need approval and what the approver sees
purchase.create is the only write and always becomes an approval request. The approver sees the supplier ID, the warehouse ID, the purchaser ID if one was given, each SKU with quantity and unit price, and the remark. When it is approved, OrgRelay calls /erp/sc/routing/purchase/purchase/createPurchaseOrder with opt_uid and purchaser_id (from the request, or the user ID in the connection settings), supplier_id, wid and a product_list of SKU, price and quantity_real. It returns the purchase order number (order_sn) LingXing assigns. A line without a price, or a connection without a user ID, is stopped before anything is sent. The purchase order support described here requires OrgRelay 1.4.0 or later.
Points for approvers:
- Supplier and warehouse are numeric IDs from LingXing, not names. Ask the requester to confirm them, or check
purchase.searchfor an earlier PO to the same supplier. - Treat the approval as the purchasing sign-off: the order commits money once your team sends it to the supplier.
- The PO is created as a normal LingXing purchase order awaiting delivery, not a draft. Changes after approval are made in LingXing.
Most sellers make the purchasing manager the approver and keep purchase.create switched off for everyone else. The e-commerce solution page shows this split between operations and purchasing. See also human-in-the-loop.
Set it up
- Sign in to LingXing ERP as the super administrator (超级管理员). Open 设置 → 业务配置 → 全局 → 开放接口, enter an email for open platform notices and click 进入开放后台. The AppID and AppSecret are shown under API 信息.
- On the same page, add the public egress IP of the OrgRelay machine to the IP whitelist (IP 白名单). Open
https://toolbox.lingxing.com/api/getIpfrom that machine to see the address LingXing will see. If OrgRelay sends traffic through an outbound proxy, whitelist the proxy's IP instead. Both the AppID and the whitelist are required. - If open API access is not active for your company, or a tool returns 2001004, contact your LingXing account manager to enable the APIs you need (orders, inventory, products, profit reports, purchasing, shipments, ads).
- In OrgRelay, open Admin → Business systems → App directory, choose 领星 ERP / LingXing ERP, enter the AppID and AppSecret, and click Connect. OrgRelay requests a token and reports how many shops it found. If purchasing will use
purchase.create, also enter the LingXing user ID that should appear as operator and default purchaser. - Grant the connection to operations, purchasing and finance roles, and decide who approves purchase orders.
- If your office internet changes its public IP, update the whitelist. Until then, every call fails with 3001002.
Limits and things it deliberately does not do
- LingXing rate limiting. LingXing uses a token bucket per AppID and API path. Each request takes a token, and the token returns when the request completes, fails or times out after two minutes. Bucket sizes are listed per endpoint. For example, the shop list, order list and purchase order list have a capacity of 1, FBA stock has 3, and the MSKU profit report and SP campaign report have 10. When the bucket is empty, LingXing returns 3001008. OrgRelay treats that as a rate limit and retries after 10 seconds.
- OrgRelay's limits: 120 calls per minute per connection, a 60-second pause after three consecutive failures, and about 12,000 characters of each result for the AI. A capacity of 1 means parallel questions against the same API wait for each other, so ask one shop at a time.
inventory.fbaalways needs a shop, so the AI callsorders.shopsfirst when nosidis known. - No sandbox. LingXing has no public test environment. Run your first approved purchase order with a test supplier or a small quantity you are ready to cancel.
- Not exposed: listing edits, price changes, FBA shipment plan creation, STA tasks, ad bid or budget changes, warehouse transfers, supplier edits and non-Amazon platform orders. These remain in LingXing.
- Order detail is returned in LingXing's own field layout rather than mapped fields, so very long orders can hit the result-size limit.
Official MCP server and OrgRelay
LingXing's open platform documentation does not describe a first-party MCP server, and the official servers page explains how OrgRelay treats vendor servers where they do exist. The platform exposes its REST API with the signing rules above. If a partner builds an MCP server on top of it and serves it over Streamable HTTP with a bearer token, OrgRelay can attach it as a third-party MCP connection (see MCP transports for what that requires). For individual LingXing APIs this connector does not cover, an OpenAPI import is not a good fit, because LingXing's per-request AES signature has no OpenAPI security scheme. A small custom connector built from the examples is the cleaner route, and the connector check tool verifies it before you bind it.
Whatever the route, OrgRelay contributes the controls: tools granted per role and department, approval before any write, one audit log across LingXing, Kingdee, Shopify and your other systems, and an installation on the company's own Mac mini. That machine is also the single, stable egress IP that LingXing's whitelist expects. The enterprise patterns page covers multi-system set-ups like this one.
Common questions
Why does LingXing return error 3001002 after I entered the right AppID and AppSecret? The request came from an IP address that is not on the open API whitelist. Add the public egress IP of the OrgRelay machine (or of the outbound proxy, if OrgRelay uses one) under 设置 → 业务配置 → 全局 → 开放接口. LingXing accepts IP addresses only, not domain names.
What does error 2001004 mean? The specific API is not authorized for your company. LingXing's error code list says to contact LingXing staff, usually your account manager, to enable it. Other tools keep working while one is blocked.
Do I need to handle access tokens or signatures myself? No. OrgRelay exchanges the AppID and AppSecret for an access token, renews it before it expires, and signs every request with LingXing's MD5 plus AES-128-ECB scheme. You only maintain the AppSecret and the whitelist.