Use a native Salla feature when it reliably covers the required workflow, then compare apps and custom integration for a demonstrated gap. The least complex solution is not necessarily the cheapest on installation day. It is one your team can operate, troubleshoot, support and leave without losing control of its data.
Start with one precise task. “Connect the warehouse” is incomplete. A useful requirement identifies the authoritative stock system, when changes must reach the store, what happens when updates fail and who reconciles differences. This makes Salla store development about an operational outcome rather than the number of installed apps.
Distinguish four implementation routes
| Route | When to investigate it | Responsibility that remains |
|---|---|---|
| Native configuration | The requirement exists in the actual account | Approve and test the rule |
| Marketplace app | A provider supports the required workflow | Subscription, permissions, support and dependency management |
| Suitable automation tool | A bounded flow connects supported systems | Platform limits, monitoring and workflow maintenance |
| Custom integration | An important gap survives the simpler alternatives | Development, hosting, operation and updates |
Inspect the capabilities available to the actual account and plan, not only a marketing page. If an app advertises “inventory sync,” ask about direction, parent-versus-variant handling, warehouse coverage and conflicting updates. The label may describe behaviour very different from your requirement.
Describe the data contract in operational language
Name the source of truth for each field. The warehouse may own quantity, the store may own descriptions and a commercial approver may own prices. Do not allow two systems to overwrite the same field without a conflict rule. Specify what must not transfer, such as internal notes the receiving system does not need.
Salla documents scoped application authorisation through OAuth. Review requested permissions against the task rather than granting broad access for convenience. Salla authorisation documentation.
An API integration and development scope should identify fields, events, supported operations, secret handling and access-revocation ownership. A buyer does not have to review every line of code to request these boundaries. They are part of defining the dependency the business will operate.
Also define deletion and correction behaviour. If a SKU is retired or renamed, will the connection stop, create a new item, or continue updating the old record? The answer matters more than a demonstration that transfers one uncomplicated product successfully.
Worked hypothetical example: warehouse stock updates
This scenario is illustrative, not a measured result for a particular product. A store has 80 sellable SKUs and a warehouse system that maintains quantities. The owner compares a reviewed periodic file, an existing app and custom integration. For this example, the business initially accepts up to one hour of update delay. That is an assumed business decision, not a recommended tolerance for every merchant.
If an employee can perform and reconcile the file update within that limit, the simpler route may be sufficient for the current phase. If inventory changes make the delay unacceptable, the merchant tests an app with representative records. The number 80 alone is not a reason to commission a custom build.
The trial includes an unavailable SKU, a replenished SKU, a variant and an identifier missing from the destination. The team interrupts the test connection through an approved method, checks whether the responsible person can see the failure, then resumes it and verifies that changes are neither lost nor applied incorrectly twice. If the app cannot expose discrepancies, that becomes a documented comparison gap.
Evaluate failure before celebrating speed
Salla documents webhook events and retry behaviour for some delivery failures. The receiver therefore needs deliberate handling of repeated delivery rather than an assumption that every incoming event is unique. Salla webhook documentation.
Request tests for repeated events, missing fields, unknown SKUs, revoked access and an unavailable destination. For each, establish whether processing stops or retries, where the issue appears, who receives it and how reconciliation works. Avoid putting customer data or credentials into broadly accessible logs merely to simplify troubleshooting.
These questions also apply to no-code development. Less custom code does not remove usage limits, recurring fees or reliance on another account. Ask what can be exported or documented when changing tools, and be explicit about what cannot be transferred.
A recovery demonstration should include the business record, not just an error screen. The useful evidence shows that a responsible person can find the affected item, understand what happened and restore an agreed state without guessing which system to trust.
Compare cost with responsibility
Separate setup fees from app subscriptions, platform charges, hosting, usage and maintenance. A proposal including monitored operation is not equivalent to one covering installation alone. Ask who retests the flow if a provider changes a field, permission or platform behaviour.
Name the contact for store configuration, the app, the warehouse system and any intermediary code. “Support included” is insufficient if every supplier can redirect the issue to someone else. The agreement should identify who assembles evidence and coordinates resolution, along with the limits of that commitment.
Include an exit scenario. Who owns the accounts? How is the connection disabled? What happens to pending changes? Can the merchant continue through a documented temporary process? A solution that is easy to install but impossible to unwind may be a poor fit for a small team.
Acceptance conditions for the selected route
Through software quality assurance, verify transferred values, timing against the agreed tolerance, failure and duplicate handling, account ownership and safe disablement. Make the selection conditional on the trial evidence, not on the app's attractive dashboard or review count alone.
Common mistakes include overlapping apps, competing stock writers, ignored exit costs and treating “connected” as synonymous with “reconciled.” Sometimes resolving the internal process is more valuable than adding another connection to an unsettled workflow.
Frequently asked questions
Is custom integration always better?
No. It can address a specific gap but introduces maintenance and operational responsibility. Commission it for evidenced requirements, not as a badge of sophistication.
Does a ready-made app still need testing?
Yes, against your data and rules. Support for a system name does not establish support for every field and exception you depend on.
Should every supplier receive the owner's password?
Do not make that the default. Use the supported authorisation and appropriate access route, with business-controlled ownership.
What should precede payment for a custom build?
A comparison and bounded trial showing the gap, evidence for the proposed route, recurring costs, responsibilities and support limits.
A useful next step
Choose one important flow and map its source, destination and failure cases. Compare native configuration, an app and a custom route against that flow before expanding the scope.
Sources
Reviewed 26 October 2026: Salla authorisation and Salla webhooks.