Orders and documents
An order can continue into ERP or accounting, receive a document number and change state without creating a duplicate.
- orders, cancellations and refunds
- invoices, credit notes and payments
- tax, currency and state mapping
Custom Shopify integrations
Connect Shopify with ERP, accounting, warehouse and internal systems.
We design data flows for orders, products, inventory, customers, documents and shipments. Each integration defines data ownership, conflict rules, diagnostics and safe retry behaviour.
An integration is not just a connection between two APIs. It has to define which system owns each data object, what happens during a conflict, how duplicates are prevented and what the team sees when only part of the workflow fails.
Data flows
Each data group needs its own direction, identifier and failure scenario.
Products, pricing and inventory
The source of truth may be PIM, ERP, warehouse or Shopify. Direction and permitted changes are defined for every object.
- products, variants and media
- price lists and market pricing
- inventory, locations and reservations
Customers and B2B
Company accounts, addresses, segments and permissions need rules for consent, access and record merging.
- customer and company profiles
- B2B pricing and approvals
- CRM segments and consent
Shipping and fulfilment
A shipping service can receive the order, pickup point and address and return a label, tracking reference and shipment state.
- pickup points and shipping mappings
- shipment and label creation
- fulfilment and tracking events
Marketing and analytics data
Events, product exports and audiences must respect consent, stable identifiers and destination-platform capabilities.
- product and advertising feeds
- events and data layer
- audiences, attribution and reporting
Operational resilience
Partial failure must not remain hidden.
Design covers more than the happy path: timeout, unavailable API, changed schema, conflicting edits and repeated webhooks all need defined handling.
Data ownership
Each object has a named source of truth and permitted direction of change.
Idempotency
A retry does not create another order, document, customer or shipment.
Diagnostics
Logs include the identifier, step and failure reason without exposing sensitive data.
Safe retries
The team can repeat one operation without rerunning the whole flow blindly.
Alerts
Critical errors and a growing failure queue have a defined recipient.
Interface changes
API versions and mappings are checked before production release.
Shopify and POHODA
Orders, inventory and documents for the actual edition and deployment.
A new connector starts with an inventory of objects, directions and permissions. It confirms which data Shopify owns, which data POHODA owns and how cancellations, documents, inventory and differing states are handled.
- Shopify → POHODA: orders, customers and agreed events
- POHODA → Shopify: products, pricing or inventory according to ownership
- Return states: document numbers, processing and diagnostics
Related services
Detailed scope by data type and workflow.
FAQ
Decisions to make before implementation.
What do you need for an initial assessment?
System names, example objects, required direction, approximate volume and a description of the current manual step or failure.
Is bidirectional sync always better?
No. A bidirectional flow adds conflict paths and is used only where both systems genuinely need to initiate changes.
How are duplicates prevented?
Stable external identifiers, idempotent operations and processed-event records are used. The exact mechanism depends on the API.
Do you support every ERP or carrier version?
Compatibility is confirmed by edition, version, permissions and interface. A third-party name does not imply support for every configuration or official partnership.
Integrations
Tell us which systems do not understand each other today.
Send an example data object, transfer direction and the failure or manual step. We will assess ownership, conflicts and safe processing.