Flieber

New Product Forecast: the organisation's products, to pick the new one to forecast (tagged new, recent, unsold, sold or discontinued, in that order, best first 90 days first) and see the others' launches. Search by code or name. Its figures are New Product Forecast's own estimate from the proxies' launches, not Flieber's actual sales, adjusted sales or forecast signals. Needs a Flieber sign-in; only for organisations set up for the Flieber portal (Flieber refuses others).

New Product Forecast: the channels a new product can be forecast in (the forecast's `channels` must be among them), most units in the last 12 months first, and the sales history the forecast reads. Its figures are New Product Forecast's own estimate from the proxies' launches, not Flieber's actual sales, adjusted sales or forecast signals. Needs a Flieber sign-in; only for organisations set up for the Flieber portal (Flieber refuses others).

New Product Forecast: forecast a product with no sales yet, month by month, from the launches of the products most like it (proxies), as the portal's New Product Forecast does. Units per month (base, low–high range, typical launch) from the forecast's first month, with the run's figures on every row: launch month, basis, whether it needs a human (best match below 0.60), totals. Computed on request; nothing is stored. new_product_candidates shows the proxies for the same inputs. Its figures are New Product Forecast's own estimate from the proxies' launches, not Flieber's actual sales, adjusted sales or forecast signals. Needs a Flieber sign-in; only for organisations set up for the Flieber portal (Flieber refuses others).

The organisation's SKU automap strategy: how new listings are mapped to products on their own, if at all.

The organisation's store connections and how far each one's import has got.

Create one inventory location. A name that exists is refused, so repeating a commit whose outcome is unknown cannot duplicate it. Preview with commit=false, then commit=true with the same arguments, preview_id and upstream_preview_id.

Create one store (a selling account) on a connection or a Google Sheet. A name that exists is refused, so repeating a commit whose outcome is unknown cannot duplicate it. Preview with commit=false, then commit=true with the same arguments, preview_id and upstream_preview_id.

Delete one store (a selling account), IRREVERSIBLE: show the preview, ask the person to type the store's exact name, and commit with what they typed as confirm_name. Its SKU mappings, daily sales and forecast go with it; its orders, products and connection stay. The preview's warnings name the store and what goes. A missing or different confirm_name deletes nothing; a repeated commit is refused (the store no longer exists). Preview with commit=false, then commit=true with the same arguments, preview_id and upstream_preview_id.

Enable the Flieber portal (the self-serve product) on the selected, existing organisation: its connections, stores and mapping carry over. Organisation admins only; Flieber refuses anyone else. A no-op when it is already enabled. Preview with commit=false, then commit=true with the same arguments, preview_id and upstream_preview_id.

Finish setup: IRREVERSIBLE, it sets the organisation live. Run onboard_state first; confirm with the user before committing. A no-op once the organisation is live. An organisation created through flieber or the portal does not need it by default: it goes live automatically after a save that leaves the setup complete. Preview with commit=false, then commit=true with the same arguments, preview_id and upstream_preview_id.

Set each store's fulfillment and storage locations: an id sets it, null clears it, omitted keeps it. Preview with commit=false, then commit=true with the same arguments, preview_id and upstream_preview_id.

Your active snoozes of the alerts about disconnected stores (a snooze is the signed-in user's own): the connection, until when, and when its outage began. Only with `--mode rest` for now: by default onboarding goes through Flieber's onboarding service, which does not offer this yet, so it is refused with nothing sent. `flieber onboard --mode rest`, or the environment variable FLIEBER_ONBOARDING_MODE=rest (it sets the default for the CLI and the local MCP server), sends onboarding to the Flieber app's own API instead, and runs it. Not on the hosted server.

The organisation's assisted-connection requests (systems Flieber connects for you) and their status. A request is filed in the portal (onboard_start_connection points there), because it carries the provider's credentials.

The organisation's inventory locations and the provider locations each stands for.

One page of a store's SKUs and the product each maps to (unmapped by default), with a suggested product code when Flieber has one.

The organisation's stores (selling accounts) with their connection and provider.

Add products and SKUs to a store, or map, move or clear SKUs, at any time, not only during onboarding, as the app's Map SKUs page and AI Lab's Add or map SKUs upload do: an upsert per SKU; a new product code creates the product, and existing product names are kept. A store holds one mapping per SKU, so mapping a SKU that is on another product moves it. Clear a mapping with clear: true (the SKU keeps its archived flag), archive with archive: true (unmaps the SKU and leaves it out of counts and forecasts; this is not Discontinued and not Sell-through), or unarchive with archive: false (only a SKU that is archived now, and it stays unmapped; do not send is_archived with a product code). Each commit makes Flieber tidy the organisation's catalog: it deletes a listing left with no SKU, with its chosen status, backorders, attributes and tier, and keeps only the newest of two mappings of one SKU. The preview shows, per row, the product the SKU is on now (current_product_code) and whether the row removes that product's listing (removes_listing). Preview with commit=false, then commit=true with the same arguments, preview_id and upstream_preview_id.

Rename one store connection: the name it shows under in Flieber, as the portal's Connect page does. Only the name changes: its stores, imports and data stay; rename it back to undo it. The name is trimmed, 1 to 100 characters, and need not be unique; the current name is refused, so a repeated commit is refused rather than applied twice (after an unknown outcome, that refusal means the rename went through). Preview with commit=false, then commit=true with the same arguments, preview_id and upstream_preview_id.

Set the organisation's SKU automap strategy, keeping its other settings. Turning it on starts mapping the unmapped listings right away; turning it off later does not undo those mappings. A custom rule is not replaced. Preview with commit=false, then commit=true with the same arguments, preview_id and upstream_preview_id.

Snooze the alerts about disconnected stores only for you (the signed-in user), for 3_days, 7_days or until_reconnected, as the app's disconnected-store banner does. Only a connection that is disconnected now can be snoozed (onboard_connection_status: disconnected or access_denied); the others are refused. The stores still show as disconnected and nothing else changes. Snoozing again replaces the end; onboard_unsnooze_alerts shows the alerts again. Only with `--mode rest` for now: by default onboarding goes through Flieber's onboarding service, which does not offer this yet, so it is refused with nothing sent. `flieber onboard --mode rest`, or the environment variable FLIEBER_ONBOARDING_MODE=rest (it sets the default for the CLI and the local MCP server), sends onboarding to the Flieber app's own API instead, and runs it. Not on the hosted server. Preview with commit=false, then commit=true with the same arguments, preview_id and upstream_preview_id.

Start connecting a store: for amazon, ebay and etsy, the consent URL the user opens in a browser; for walmart, bigcommerce, woocommerce, bol, shopify and the assisted-setup systems (netsuite, 3PLs, ...), where to connect instead. Nothing is saved until the user consents; then onboard_connection_status shows the new connection.

Onboarding status of the signed-in user's selected organisation: whether it is live and, for an organisation with the app's steps, whether finishing is allowed now and what blocks it, as Flieber reports (flieber derives no steps). An organisation created through flieber or the portal (products include portal) has no setup steps: by default it goes live automatically after a save that leaves the setup complete (a store and a mapped listing), never on a read; that save's preview says it may, and its result says it did. Needs a Flieber sign-in.

Show the alerts about one disconnected store again, for you: removes your snooze of that connection, as the app's 'Show alerts again now' does. A no-op when it is not snoozed. Only with `--mode rest` for now: by default onboarding goes through Flieber's onboarding service, which does not offer this yet, so it is refused with nothing sent. `flieber onboard --mode rest`, or the environment variable FLIEBER_ONBOARDING_MODE=rest (it sets the default for the CLI and the local MCP server), sends onboarding to the Flieber app's own API instead, and runs it. Not on the hosted server. Preview with commit=false, then commit=true with the same arguments, preview_id and upstream_preview_id.

Change one inventory location; omitted fields stay as they are. Preview with commit=false, then commit=true with the same arguments, preview_id and upstream_preview_id.

Change one store (a selling account) as the app's Edit store dialog does: its name, region or wholesale flag; a field left out stays as it is. A commit changes only those fields (flieber sends the whole record, the other fields unchanged); change it back to undo it. Changing the wholesale flag queues a forecast rebuild for the store (asynchronous: forecast reads show it once the rebuild finishes; a wholesale store's sales history is not cleaned of outliers). A repeated commit sets the same values again. Preview with commit=false, then commit=true with the same arguments, preview_id and upstream_preview_id.

Withdraw one open assisted-connection request (a system the Flieber team is connecting for you), as the app's Integrations page does: the request is deleted and the team stops setting it up. It cannot be undone: to connect that system later, file a new request in the portal, which takes its credentials again (flieber never handles them). A completed request is refused, and so is a repeated commit (the request no longer exists). Only with `--mode rest` for now: by default onboarding goes through Flieber's onboarding service, which does not offer this yet, so it is refused with nothing sent. `flieber onboard --mode rest`, or the environment variable FLIEBER_ONBOARDING_MODE=rest (it sets the default for the CLI and the local MCP server), sends onboarding to the Flieber app's own API instead, and runs it. Not on the hosted server. Preview with commit=false, then commit=true with the same arguments, preview_id and upstream_preview_id.

Check the API key and the connection: returns the organisation the key reads and the environment called.

For the demand-forecast view only (not for agents): one of its Flieber REST reads, forwarded as the portal sends it.

The organisation's products, with the ids the signal capabilities filter by. Search by code or name.

What to order or transfer for a coverage period, before any plan exists: the replenishment needs per product × destination from the current inventory forecast, as the Flieber app shows an unsaved plan. Narrow it by type, destinations, suppliers, origin locations or product × location pairs; as in the app, only active products unless include_discontinued. meta.summary holds totals over every listed line, not just this page (replenishment_needs, replenishment_needs_purchase_cost, total_inventory_value, in USD), and the origins and destinations by name. It saves nothing and creates no plan. Needs a Flieber sign-in.

Each inventory location's replenishment parameters, as the Flieber app's Settings → Replenishment parameters page shows them: safety stock, target days of coverage and overstock trigger, in days. Needs a Flieber sign-in.

Each product's replenishment parameters at the locations it is stocked at, as the Flieber app's advanced replenishment parameters show them: the value that applies, whether it is the product's own or the location's, and the location's value. Needs a Flieber sign-in.

Override a product's safety stock, target days of coverage or overstock trigger at a location, or make it follow the location's value again, as the Flieber app's advanced replenishment parameters do. A commit replaces the product's own values at that location (the preview shows the previous ones; set them again to undo); a parameter an item does not name stays as it is. Preview first (commit=false), then commit with the preview_id. A commit makes Flieber recalculate the inventory forecast in the background (meta.warnings says so): inventory forecast reads may show old numbers for a few minutes. Needs a Flieber sign-in.

Set or clear inventory locations' safety stock, target days of coverage and overstock trigger, as the Flieber app's replenishment parameters page does. A commit replaces those values (the preview shows the previous ones; set them again to undo); a parameter an item does not name keeps its value. Preview first (commit=false), then commit with the preview_id. A commit makes Flieber recalculate the inventory forecast in the background (meta.warnings says so): inventory forecast reads may show old numbers for a few minutes. Needs a Flieber sign-in.

One replenishment plan as the Flieber app shows it: a page of its lines (product × destination: needs, the units it orders, cost, days of stock), and in meta.summary the plan itself (as replenishment_plans lists it), totals over every listed line, not just this page (replenishment_needs, order_units, replenishment_needs_purchase_cost, total_inventory_value, in USD), its origins and destinations by name, and container use (how its order units fill 20GP/40GP/40HC/45HC containers, with warnings such as products missing carton dimensions; only where the carton dimensions editing feature is turned on, else meta.warnings says it is left out). Lines are computed for the plan's own coverage period. As in the app, lines and totals leave out products that were discontinued when the plan was calculated (product_status_at_creation; product_status, today's, where none was recorded) unless include_discontinued; origins, destinations and container use cover every line. Needs a Flieber sign-in.

Convert one saved replenishment plan into inbound shipments, as the Flieber app's Convert to shipments does: Flieber creates one shipment per destination from the plan's lines and marks the plan converted. It runs once and cannot be undone: nothing in flieber or Flieber's API reverses it, and the shipments count as incoming stock in the inventory forecast, which Flieber recomputes asynchronously. The preview (commit=false) changes nothing and lists the shipments it would create (code, destination, delivery date, each product's quantity), computed from the plan's lines with Flieber's rule. Only a completed plan (not a legacy one) that is not converted and has something to ship converts; a plan with more than 400 lines is refused (convert it in the app). Show the person the preview; then ask them to type the plan's exact name, and commit with the preview_id, the preview's upstream_preview_id (a digest of its shipments) and what they typed as confirm_name. A missing or different confirm_name converts nothing; a plan changed since the preview is refused with preview_mismatch and converts nothing. The commit lists the shipments it asked Flieber to create; run replenishment_plan and inventory_shipments to confirm. Needs a Flieber sign-in.

Create a replenishment plan (purchase or transfer), as the Flieber app does from the inventory forecast: a snapshot of the order units the scope's lines need over the coverage period. The preview (commit=false) writes nothing: it checks the scope against the supply chain, reports the purchase/transfer collisions and how many lines and units the plan would take. A commit creates the plan (Flieber names it 'Replenishment Simulation <date time>') and saves a draft, as the app's Save. Not idempotent: each commit creates another plan. It can be undone only by deleting the plan in the app. It changes no inventory forecast number and starts no recompute: a plan is a snapshot. Needs a Flieber sign-in.

Delete one replenishment plan, as the Flieber app's Delete does. It cannot be undone: the plan and all its lines are removed for the whole organisation; shipments it was converted to stay, and only lose their link to it. It changes no inventory forecast. Preview first (commit=false) and show the person the plan; then ask them to type the plan's exact name, and commit with the preview_id and what they typed as confirm_name. A missing or different confirm_name deletes nothing; a repeated commit is refused (the plan no longer exists). A legacy (v1) plan still calculating is refused, as in the app. Needs a Flieber sign-in.

Edit a replenishment plan as the app's plan editor does: order units per line, the coverage period (and a transfer's departure), round every order up to whole cartons, reset every order to the computed needs, or save a draft (complete). The preview (commit=false) shows each change before and after and writes nothing. A commit changes the plan's lines and settings only. It is not undone by flieber: set the old values again (the preview shows them); round_to_cartons and use_replenishment_needs replace every order set by hand. A plan converted to shipments is not edited. It changes no inventory forecast number and starts no recompute: a plan is a snapshot. Needs a Flieber sign-in.

Refresh a replenishment plan from the latest inventory forecast, as the app's refresh does: its lines are taken again for the same products and destinations, for its coverage (or a new one). The preview (commit=false) writes nothing. A commit replaces every line (new line ids); order units set by hand above 0 are kept and an explicit 0 is lost. It can't be undone. A plan converted to shipments is not refreshed. It changes no inventory forecast number and starts no recompute: a plan is a snapshot. Needs a Flieber sign-in.

Rename a replenishment plan, or change its comments, as the app's name and comments dialogs do. The preview (commit=false) shows the name and comments before and after and writes nothing. A commit changes only those; rename it back to undo. Needs a Flieber sign-in.

The organisation's replenishment plans (purchase and transfer plans), newest first, as the Flieber app lists them: completed plans unless status asks for drafts (pending). Filter by type, supplier, origin or destination location, creation date or name. Needs a Flieber sign-in.

Download a finished report. The flieber CLI saves the file on this computer (--out, else a safe name in the current directory; --force to replace a file) and returns where. The MCP saves no file and gives the report's status and the Flieber app's Reports page, where the person downloads it. No result carries a link to the file. Needs a Flieber sign-in.

Start reports, as the Flieber app's Create report dialog does: one per report type (SALES_FORECAST_ADJUSTED, SALES_FORECAST_ADJUSTED_EXTENDED, SALES_FORECAST_MONTHLY_ADJUSTED). A commit asks Flieber to build each report in the background (CREATED, then RUNNING, then COMPLETED or FAILED; follow it with reports, then report_download). It adds a report to the organisation's list and changes no other data: no forecast, inventory or setting, and no inventory-forecast recompute. It is not undone by flieber or the app (neither deletes a report), and each commit starts new reports, so repeating it makes more. Preview first (commit=false; it calls nothing), then commit with the preview_id. Needs a Flieber sign-in.

The organisation's reports, as the Flieber app's Reports page lists them: type, status, whether a schedule started it, and when it was requested and finished; newest first unless sorted. A COMPLETED one can be downloaded with report_download; report_request starts a new one. Needs a Flieber sign-in.

Actual sales: the units and net revenue each channel recorded, per period and per product, store or product × store. Only actual sales, never adjusted or forecast values. Default: weekly, the 90 days ending yesterday. No date after today; for the future use `forecast`.

Sales analytics ledger, as the app lists it: one row per product × store with its actual sales over a period (units, net revenue, per day, average price), its share of the organisation's totals, and the same period a year earlier with the relative change. Default: the last 365 days, to yesterday. Only active products unless include_discontinued (or product_status discontinued). Needs a Flieber sign-in. For actual sales per week or month use `sales`; for one row per tier, store, product or attribute value use `sales_trends_grouped`.

Sales analytics ledger grouped, as the app's group-by lists it: one row per product, store, tier or value of one product attribute, with its actual sales over a period (units, net revenue, per day, average price), its share of the organisation's totals, how many product × store rows it holds, and the same period a year earlier with the relative change. Default: the last 365 days, to yesterday. Only active products unless include_discontinued (or product_status discontinued). Needs a Flieber sign-in. For one row per product × store use `sales_trends`.