Your role in the network
Establish the partnership model and the account context before commercial work.
Inputs: Manufacturer identity, product categories, channel goals, team responsibilities, target geography, existing reseller relationships, and available AI/MCP access. Accept owner-provided information where connections are not ready.
Phase
Lesson work and checkpoint
A · Map the model
Explain manufacturer, Randmar, reseller, end customer, and AI-agent responsibilities. Identify who owns product truth, qualification policy, offers, customer relationships, demand generation, ordering, and support.
B · Establish access
Review supported AI setup. Resolve the authenticated application and target manufacturer separately; verify role/capability through the documented account flow. Record connected, not connected, or unavailable with evidence.
C · Assess readiness
Read permitted account/profile, category, and reseller context. Identify usable portal, registration, public-resource, and training links. Separate missing facts from missing permissions.
D · Set the first cycle
Choose one practical product/category focus and partnership objective. Assign an owner and review date to each blocker. Confirm the first-cycle scope with the manufacturer.
Required final results PDF
Partnership & Platform Readiness Map: business context; role/responsibility matrix; current channel model; account and capability checklist; selected focus; access gaps; prerequisite actions with owners; first-cycle success measures; source and verification log.
Completion checks
The learner can explain the six-step Handbook sequence and distinguish manufacturer authorization from reseller authorization. Every claimed connection has a successful read or a clearly labeled untested state. No credential values appear in the output.
Platform grounding: manufacturer account details and Partner role checks are documented. Profile links can be read; their presence in a schema is not proof that an arbitrary field setter exists. Connection/setup and permissions are prerequisites, not invented in-page integrations. [R-Q, S4-S6]
Four distinct relationship states
Teach these distinctions before a learner changes access or launches an offer.
State
What it means What it does not prove
Program policy
Manufacturer-defined criteria, benefits, training, decision process, review rules, and optional tiers.
A native certification engine, completed
training, or an applied qualification.
Manufacturer
qualification
A recorded relationship/value for a
particular manufacturer and reseller; can affect applicable access/pricing.
Assignment to every Opportunity or a universal
reseller certification.
Opportunity assignment
A reseller is included in a particular manufacturer bid, with separately verified products, prices, dates, and status.
That the reseller selected it as default or
synchronized a store.
Reseller activation
Supported use of the offer; optional default selection, store synchronization, merchandising, and launch verification.
That queued work finished, all cart lines
changed, or a campaign generated sales.
Illustrative walkthrough - fictional names and values
A fictional manufacturer, Northlight, defines a specialist reseller program requiring category knowledge, approved claims, and a service owner. Cedar Retail supplies a strong Playbook brief but lacks product training. The manufacturer records a development plan before any qualification change.
After the owner approves the evidence and a validated qualification value, the authorized agent reads the current relationship, previews the replacement and notification effects, applies the change, and verifies it. A separate Opportunity, SPRING-DEMO, is prepared with resolved SKUs, reviewed pricing types, dates, and an approved roster.
The bid is initially quote-only and therefore inactive. Activation requires an explicit reviewed change. Cedar's assignment is independently verified. In an authorized reseller context, Shopify synchronization is queued and later checked against actual products. Only then is store readiness recorded; demand generation follows the joint calendar.
The loop returns to policy and execution
An expiry warning may lead to a reviewed renewal proposal. Renewal creates another bid, retaining the original
and copying pricing and assigned resellers with notifications. Re-check the roster and commercial terms; do not treat renewal as a harmless date edit.
All names and the bid number in this example are illustrative. No example qualification code, price formula, benefit, or commercial promise should be copied into a live account without validation. [R-Q, R-O]
Read, prepare, approve, verify
Keep the AI workflow useful while respecting real roles and effects.
Step
Implementation requirement
1 · Discover
Use Randmar MCP search_api_endpoints and get_endpoint_details. Execute only the exact returned operationId and documented schema. Revalidate current contracts during implementation and before unfamiliar actions.
2 · Resolve identity
Authentication comes from MCP context. If the application ID is unknown, use get_current_application_id. Follow documented onboarding if none exists. Read Partner account roles for a non-admin caller.
3 · Bind the target
routeManufacturerId and routeResellerId identify the target business. Admin identities 2/FGDCT3037 do not become the target route ID. Select the correct partner type and verify permission.
4 · Read and prepare
Read current records. Resolve returned IDs/SKUs/category codes. Prepare an exact diff including dates, values, roster, affected records, cost/access effects, and any notifications or sending behavior.
5 · Review authorization
Present a concrete reviewable action. Follow applicable endpoint confirmation rules and the user's authorized scope. Do not request repeated permission for the same unchanged authorized action.
6 · Execute and inspect
Use the appropriate supported executor. HTTP status alone is insufficient: check boolean body, errors, returned identifiers, and partial results. A POST report may be read-only in effect; inspect semantics.
7 · Verify and record
Re-read the saved state or verify the actual external result. Record source, timestamps, before/after, approval, outcome, remaining issues, and next action. Retry only after inspecting current state.
Required user-facing action states
Proposed → Ready for review → Authorized → Attempted → Verified, with branches for Failed, Partial, Queued, Unresolved, Deferred, and Already in desired state. These are product design states, not claims about native Randmar enums. Preserve a concise event history.
For HTTP 200 false, read back to distinguish an existing assignment, rejected input, missing record, or failed change. Never silently convert false to success. For a lost response, reconcile before repeating a notification, upload, order, renewal, or queue operation.
Credentials and communications: never collect or expose tokens in prompts/PDFs. Do not send partner messages without explicit instruction or an applicable authorized workflow. Explain embedded notifications when reviewing assignments, qualification changes, renewals, and sending operations. [R-Q/R-O/R-C/R-S]
Design for the actual platform
Use these constraints in prompts, examples, UI states, and developer tests.
Area
Verified behavior and required handling
Catalog fields
Field updates have a case-sensitive whitelist and scalar newValue. BodyHTML carries unsupported descriptive specifications. Product-header MAP/MSRP and Distribution.MAP/MSRP are distinct; do not collapse them.
Margins and categories
Margins are category-level. Readable A_GP/B_GP/C_GP/D_GP/Cost_GP fields are not proof of edit support or program tier codes. The category editor does not expose arbitrary margin or lead-time setters.
Media and attachments
Images have IDs, order, and primary selection; multi-upload rollback can be incomplete. Re-read before retry. Attachment registration needs a StorageKey; the referenced upload operation was not exposed in inspected MCP search results.
Stock and reports
Inventory valuation is money, not stock units or availability. Inventory detail is dated. A reorder report recommends; it does not create a requisition. Explicitly bound report dates and record warehouse codes.
Purchasing
A draft requisition, a credit check, PO creation, and PO sending are different operations. Credit checks reserve nothing. PO creation may consolidate/cancel requisitions; sending defaults must be made explicit.
Service policy
RMA reads show statuses, quantities and reasons; they do not accept or credit a return. Warranty, service promises, training completion, review schedules, and content rights require agreed policy and evidence.
Measurement
Randmar sales are not reseller retail sell-through. SalesStatistic fields do not alone provide reseller or bid attribution. Use actual returned order/invoice identifiers when available; document coverage limits.
Graceful fallback requirements
If a connector, field, upload, verification method, or scheduler is unavailable, preserve the completed planning work and produce an exact manual handoff: target, proposed values, owner, supported route/UI, evidence required, and next check. Use Needs setup or Unverified, never a fabricated success.
Attachment upload discovery is a specific implementation dependency: the registration contract references a Partner Attachment/Upload route, but an executable operation was not found in the inspected search. Do not substitute Generation/Upload or pass a public URL as a StorageKey. [R-C]
Qualifications and catalog
Verified contract excerpts summarized from MCP discovery; refresh before implementation.
Notation: M = /V4/Manufacturer/{routeManufacturerId}; R = /V4/Reseller/{routeResellerId}; P = /V4/Partner/{routeApplicationId}. Braces are route parameters, not literal IDs. These paths identify contracts; discover their current executable operationIds.
GET M/Account Manufacturer profile and sales data; withSpecification adds statistics, active orders and categories. Resolve caller role separately through Partner account context.
GET M/Resellers and M/Reseller/{resellerId} Associated resellers and manufacturer-specific qualification/sales context. Detail with specifications adds completed orders, returns and Opportunities. Read before changing the relationship.
PUT / DELETE M/Reseller/{resellerId}/Qualification PUT query newValue assigns/replaces, deleting the prior qualification first. Successful qualifying values notify subscribers and log communication. DELETE removes; false is not successful removal. GET M/Reseller/Qualification/{qualificationId} provides qualification lookup.
PUT R/Manufacturer/{manufacturerId} Requests or records the relationship; optional introductionMessage may notify the manufacturer. A processed request is not sufficient evidence of the resulting qualification. Read back.
GET M/Categories and M/Category/{categoryCode} Category codes, margins and settings; margins are category-level. Category detail can omit per-product Distribution when there are 60+ products. Inspect products individually as needed.
POST M/Category/{categoryCode}/{fieldName} Exact editable fields: WeeksOfStocking, CategoryName, Starred, AutoReorder, QualificationRequired, Niche. Unknown field/category can return 200 false. Setting WeeksOfStocking empty or equal to the manufacturer default clears the override.
GET M/Products and M/Product/{productNumber} Product lookup accepts SKU/MPN/UPC. Validate manufacturer and resolved SKU. Specifications are included by default; use them for owned-product and operational inspection.
POST M/Product/{productNumber}/{fieldName} Exact whitelist only, scalar query newValue. Supported examples include Title, BodyHTML, CountryCodeOfOrigin, dimensions/weight, MasterCarton, SkidQuantity, Category, MAP, MSRP, StandardCost. Refresh full schema. State changes require explicit request; do not infer unsupported specification setters.
POST M/Product/{productNumber}/UPC Separate identifier operation removes existing mapping before replacement. Resolve by SKU/MPN; new UPC integer normalizes to 11-14 digits. Verify afterward.
GET / POST / PUT M/Product/{randmarSKU}/Images; /Video; /Attachment GET Images supports gallery inspection; discover exact image-mutation contracts. POST Video uses multipart upload. PUT Attachment requires a StorageKey. Its referenced Partner Attachment/Upload operation needs executable discovery; do not substitute Generation/Upload.
Reference boundary: a schema field is not an edit capability. Media rollback may be incomplete. Program tiers, reviews, training records, entitlements and content rights remain policy/records unless additional supported capabilities are confirmed.
Opportunity lifecycle and activation
M and R abbreviate the manufacturer and reseller base paths defined on page 29.
GET M/Opportunities; M/Opportunity/{bidNumber} List headers; detail returns roster and bid lines. withSpecification=true enriches products but excludes lines whose product cannot be fetched. false retains raw unexpanded details.
PUT M/Opportunity Creates header with BidNumber, BidTitle, Description, DefaultResellers, StartDate, EndDate, QuoteOnly. Number/title nonempty, number unused; start within one year before server time; end not past and after start. QuoteOnly=true creates inactive. 200 false can mean rejected validation. Add lines/access separately.
POST M/Opportunity/{bidNumber}/PartNumber/{randmarSKU} bidPrice must be nonnegative and SKU owned by manufacturer. Exact bidPriceType: Fixed, ItemRebate, ItemCost, ItemCostGP, ItemRebateGP; default ItemRebate. randmarDiscount=true requires SuperAdmin. Do not invent economic formulas.
POST M/Opportunity/{bidNumber}/{fieldName} Only EndDate, Active, Opportunity, Description, DefaultResellers, CanBeSetAsDefault are documented supported fields. Unsupported field/missing bid returns false. Inspect the current schema and meanings before editing.
PUT / DELETE M/Opportunity/{bidNumber}/Reseller/{resellerId} Assignment is separate from qualification. PUT existing assignment returns false; new successful assignment sends subscriber emails and records communication. Inspect DELETE contract before removal; do not assume cascade from qualification withdrawal.
PUT M/Opportunity/{bidNumber} Renewal creates a new bid with supplied new number/title/dates/quote-only flag. Copies description, default settings, product pricing and assigned resellers; retains original and notifies copied resellers. Preview the copied scope.
POST M/Opportunity/{bidNumber}/Reseller/{resellerId}/Email Explicit Opportunity email operation exists. Inspect its current inputs and effects before any authorized send; this is not permission for arbitrary broadcasts.
GET R/Opportunities; R/Opportunity/{manufacturerId}/{bidNumber} Inspect currently available offers and products/prices in an authorized reseller context. withSpecification=false supports unexpanded inspection.
PUT R/Opportunity/{manufacturerId}/Default Check CanBeSetAsDefault before offering this action. Query opportunityNumber selects default; empty clears. Applies only to future relevant default-opportunity cart additions. Existing cart lines are not rewritten.
GET R/Shopify/Accounts Resolve the exact linked shopifyHostName under the authorized reseller. Manufacturer role alone grants no authority over that store.
POST R/Opportunity/{manufacturerId}/{bidNumber}/Shopify Linked store required and reseller not on hold. Queues SyncShopifyProducts for eligible products; may create/update many products and records audit/notification messages. true means queued, not verified. Do not requeue blindly; discover supported completion checks.
Response schemas and descriptions may expose different levels of detail. Test actual shapes in an authorized safe context and preserve explicit partial/unresolved states. No atomic all-or-nothing offer setup or universal attribution capability is assumed.
Reports, supply, and service
Read evidence first; keep operational actions and sending states distinct.
POST M/Report/Sales/JSON Always pass explicit startDate and endDate. Both omitted dates can default to the first day of the current server month. Record grouping and coverage; SalesStatistic alone contains Day, ExtendedPrice, Quantity, RandmarSKU, not reseller or bid identity.
GET M/Inventory/Value Valuation by location/category includes inventory and open sales/purchase orders. It is not SKU unit availability, available-to-promise stock, or a delivery promise.
POST M/Report/Inventory/JSON inventoryDate requests an as-of snapshot; default is today. Line value is quantity × cost. Preserve date, warehouse and coverage for comparisons.
POST M/Report/Reorder/{warehouseLocation}/JSON Use the warehouse business code. Returns recommendations only; no requisition is created.
GET / POST M/Document/ActiveOrderDetails; M/Report/OpenOrders/JSON Inspect open demand. Legacy emailAddress on the JSON report is ignored; it does not send an email. Method alone does not determine whether an endpoint mutates business state.
GET M/Document/PurchaseOrders; M/Document/{documentNumber} Read PO lists then details. Requisition/receipt list routes also exist and require current discovery. Check exact document identities, manufacturer, warehouse and status.
PUT M/Requisition Creates a draft requisition, not a PO. Prepare exact warehouse, reference, resolved SKUs and quantities; inspect required body schema and approval requirements first.
POST M/PurchaseOrder/CreditCheck Tests requisition/hold/inventory-value constraints. Creates nothing and does not reserve credit.
PUT M/PurchaseOrder Combines requisitions for one manufacturer and warehouse; may cancel superseded requisitions. Explicitly set sendToManufacturer, whose default is true. false creates without sending. Inspect actual returned record.
PUT M/PurchaseOrder/{number}/Send Uses configured supplier delivery, which may be EDI and/or email. A retry can resend. PO creation does not prove delivery. Verify and record sending outcome separately.
GET M/Returns RMA list includes product, quantity, reason, status, dates, reseller and invoice/credit links. Read does not accept, receive or credit a return. Unverified service commitments remain policy proposals.
Additional discovery: product/reseller sales-statistic endpoints accept date windows; product defaults can cover the prior year through server time. PO expected-date editing exists, but the controller does not validate date format; inspect the current contract and validate the intended date before a requested edit.
Executor choice: read-only executor is for supported GET operations. POST reports may require the general executor despite read semantics. No live report request or operational action was executed to produce this handoff.
Sources and reference links
Reference snapshot from the supplied handoff, September 26, 2026. Verify current capabilities before execution. If a linked reference is unavailable, record the gap and ask for it when needed.
- Randmar Handbook - current entry point — https://randmar.io/handbook
- Randmar Workbook - experience and module pattern — https://randmar.io/workbook
- Randmar Playbook - companion reseller journey — https://randmar.io/playbook
- Randmar manufacturers - partnership context — https://randmar.io/manufacturers
- Randmar AI setup / Codex — https://randmar.io/codex
- Randmar API documentation - public reference — https://api.randmar.io/index.html
- Supplied reseller social strategy and Daily Hustle source — https://docs.google.com/document/d/1TqmH_v-ICLGHRninuvKtx9GLPH4xzBaY8Gdt5jXTz_o/edit?tab=t.42d8zb9jppjx
- Supplied Blog Calendar reference — https://drive.google.com/file/d/12XBsL7n3-uGpI9oJrrstqkEWyO1DteG1/view
- Supplied Blog Audit reference — https://docs.google.com/document/d/1bEimtlyAJJMUfkhESjqsAN9eHB3j5ZKgOjJ2Z8uLnhI/edit?tab=t.0
- Official scheduled-task documentation — https://learn.chatgpt.com/docs/automations?surface=app