Public Marketplace Eshop integration: onboarding and merchant workflows

A connection to Public Partners Marketplace starts by confirming the merchant relationship and the technical capabilities available to that seller. Preparation covers catalogue data, stock, orders and fulfillment procedures. A third-party seller programme does not by itself prove a specific API technology or complete automation. Scope should follow current merchant documentation and practical account access.

Public operates a Partners Marketplace programme for participating sellers. Before designing a bridge, we request the account’s current specifications and establish which data can be exchanged. Building a connector does not replace commercial merchant acceptance. Responsibilities should also be clear when platform requirements change: someone must own communication about new file formats, revised access or onboarding checks rather than treating integration as a one-time export.

Vague titles, incomplete attributes and changing identifiers complicate any catalogue connection. We prepare identifiers, specifications, images, prices and availability against the final partner requirements. Product identity is separated from the merchant’s offer. This distinction helps staff understand whether a discrepancy relates to the wrong item being matched or to an incorrect commercial value such as price or sellable quantity.

Third-party orders need clear channel identification and coordinated delivery and return handling. We document which state corresponds to each real action. A local record being created is not evidence that a parcel has shipped. Automatic update capabilities are confirmed in the seller environment, not attributed to undocumented endpoints. Any remaining manual action needs an owner, a visible queue and a way to confirm completion.

Consider a business with different quantities in two warehouses. It decides to offer the Public channel only stock fulfillable from its central warehouse. The proposed bridge applies that rule, preserves channel identifiers and alerts staff to pending work. Pilot orders are compared with the actual picking process. If the available seller environment requires a manual action, that step is documented explicitly. This scenario illustrates operational design; it is not a claim of platform certification, existing account approval or a result obtained for a specific customer.

Delivery includes a sample catalogue, mapping table and failure scenarios. Tests cover mismatched prices, unavailable items and a state change after cancellation. Data transfers retain a history so support can see what was sent and when. Acceptance is measured against the real partner account and the agreed operating process. A demonstration using assumed platform capabilities should not substitute for checking the merchant environment and the final published offer.