How ERPNext Shipping connects to SendCloud and LetMeShip
If your ERPNext team ships from Delivery Notes and needs carrier rates, printed labels and tracking numbers without retyping them, the ERPNext Shipping app is the component that does this work. Introduced in version 13, it compares rates from several providers, generates labels and tracks shipment status. Each carrier platform is reached through its own provider connector, and each connector needs its own API key. For SendCloud and LetMeShip, that means you create or obtain credentials in each platform's account, store them in the ERPNext Shipping settings, and test them before any warehouse user depends on them. Because the keys belong to your merchant accounts, confirm with each provider who can issue them, how they are rotated and which account they are tied to, before you plan the rollout. The Shipment document is where the results land. It is created against a Delivery Note or independently, and it records the AWB number, the shipment status and the carrier used. Those three fields are what your team will check when a customer asks where an order is, and what finance and customer service will look at when a label was reprinted or a parcel was sent by a different carrier than planned. Decide early who may create Shipment documents, who may cancel them and whether the AWB number must be present before a Delivery Note is marked complete. These are access and process choices in your ERPNext roles and workflow, not defaults you can assume. This section covers only how the connectors and the Shipment document fit together. It does not cover the rate tables, package dimensions, carrier contracts, label printer hardware or the configuration of each carrier's own dashboard, and it does not state which carriers each platform supports in your country. Confirm those points with SendCloud, LetMeShip and the ERPNext Shipping documentation for your version before you scope the work. The ERPNext Shipping documentation is the natural next read for the settings themselves.
What you need before connecting a shipping provider
Connecting ERPNext to a shipping provider touches the ERPNext version, the Shipping app, provider credentials and the carrier accounts your dispatch team already uses. Work through these items before any configuration, because each one decides what can be tested and who can approve the go-live.
ERPNext version 13 or later
The ERPNext Shipping app and the Shipment document were both introduced in version 13, so any site older than that needs an upgrade before this integration is possible. Confirm which major version your site runs and whether it is on a version still listed as supported. Check the current support status on the Frappe supported versions page before you plan the upgrade window, because the answer changes over time.
ERPNext Shipping app installed
The shipping features are delivered by the ERPNext Shipping app, which must be installed on the same bench or Docker image as ERPNext and matched to your site's version. Ask whether your hosting model (Frappe Cloud, Docker Compose or a manual bench) allows you to add the app yourself or requires your provider to do it. Record the app version in your change log so that future upgrades do not break the carrier connection.
SendCloud or LetMeShip account and API key
Each carrier aggregator needs its own account and API key, and the key is stored in ERPNext so the app can request rates, create labels and read tracking events. Decide which account will own the key and who rotates it, because a key tied to a departed employee becomes a single point of failure. Confirm with the provider how keys are issued, scoped and revoked before you store them in a production site.
Test or sandbox account
If the provider offers a test or sandbox environment, use it to validate rate comparison, label generation and tracking updates before any live shipment is created. A test account avoids printing real labels and creating real charges during configuration. Ask the provider whether the sandbox mirrors live carrier services or only returns sample data, since that limits what the test can prove.
Shipping methods and carrier contracts
List the shipping methods your customers choose and the carrier accounts your business already holds, including any negotiated rates. ERPNext needs these mapped to Shipping Rules and carrier services so that rate comparison reflects what you actually pay. Missing contracts or unclear service levels are the most common reason rate comparisons disagree with invoices after go-live.
Hosting and network access
Confirm that your ERPNext server can make outbound HTTPS calls to the provider's API and receive any callbacks your configuration requires. Firewalls, proxies and egress rules in a private network often block these calls silently. Also confirm where API keys are stored and who can read them, since the same site permissions control both shipment documents and credentials.
Configuring the connection in the order it works
This sequence takes the Shipping app from a clean install to a verified loop: rates quoted on a real order, a label printed, and a tracking number reflected back on the Shipment. Each step ends with a check so a failure surfaces at the step that caused it.
Install the ERPNext Shipping app
Your ERPNext administrator installs the ERPNext Shipping app on a non-production copy of the site first, matching the ERPNext version your site runs. The app ships with the Shipment document from version 13 onward, so confirm your version before you start. Done when the app appears in the installed apps list and the Shipment DocType opens from the search bar without errors.
Create the API key at each provider
Your shipping administrator creates an API key in the LetMeShip and SendCloud accounts you intend to use, under the account's developer or integration settings. Each connector needs its own key, so do not reuse one key across providers. Store the keys in your password manager, and confirm with each provider which account, sender address and contract the key is tied to. Done when you can see the key in the provider's dashboard and know which carrier services it can book.
Enter the keys in the Shipping settings
An ERPNext user with the System Manager or equivalent role opens the shipping settings and enters the API key for each connector, keeping the sandbox and live credentials separate where the provider offers both. Save the settings, then reopen them to confirm each connector shows as enabled. If a connector fails to save, check the key for leading or trailing spaces and confirm the account is active at the provider. Done when each connector saves without error and the provider's account shows the connection as active.
Define shipping rules and carrier services
Your operations lead maps which carrier services are offered for which destinations, weights and order values, using shipping rules and the carrier service list in ERPNext. Agree these rules with the team who packs and ships, because they decide which rate appears on a Delivery Note. Confirm the carrier services the provider returns match what your contract covers. Done when a sample destination returns the expected services in a rate request and no service appears that your team cannot book.
Test a rate request on a sample Delivery Note
A user with stock and sales permissions creates a Delivery Note for a test customer and item, then requests shipping rates from the Shipment form. Compare the rates returned by LetMeShip and SendCloud with what your carrier contracts say you should pay, and note any differences. Confirm the parcel dimensions and weight are the ones you will use in production. Done when both connectors return rates for the test order and the figures reconcile with the contract terms you were given.
Generate a test label
Using the provider's test or sandbox mode where one is offered, book the selected service from the rate request and generate a label. Print it on the printer and label stock your warehouse uses, and check that the barcode scans and the sender, recipient and reference fields are correct. Confirm with the provider whether test labels are billed or can be voided. Done when the label prints legibly, the barcode scans, and the Shipment record shows an AWB number and the chosen carrier.
Confirm a tracking update
Take the test shipment through the carrier's test scan events, or wait for the provider's status updates where the sandbox supports them, and watch the shipment status change in ERPNext. Check that the status shown on the Shipment matches the status in the provider's portal. If the status does not update, check the connector's scheduled sync and the provider's notification settings before assuming a fault. Done when the Shipment status moves from its initial value to the expected event with no manual edits.
How rate comparison, labels and tracking flow through the Shipment document
The Shipment document is the point where rate comparison, label creation and tracking meet, so it is the first thing to understand when planning this integration. In ERPNext, a Shipment is created from a submitted Delivery Note or independently, and it records the carrier, the AWB number and the shipment status. Creating it from the Delivery Note keeps the link between the goods that left the warehouse and the parcel that carries them, which matters for stock and for customer queries. Creating it independently suits returns, samples or dispatches that have no matching sales document, but the team should agree in advance how those shipments are tied back to accounting and stock records.
Some of this flow runs entirely inside ERPNext: the document links, the stored fields, the permissions on who can create or edit a Shipment, and the print formats used for dispatch paperwork. Other steps depend on the provider. Rate quotes, label files, the AWB number and every status change come back from the carrier integration through its API, using the API key configured for SendCloud or LetMeShip. ERPNext can only display what the provider returns, so if a provider omits a status, delays it or uses a status name the team did not map, the Shipment will show the same gap. Confirm with each provider which events and statuses its API sends, and test how a cancelled or partly delivered parcel appears on the Shipment before go-live.
Plan the test sequence before relying on it: create a Shipment from a test Delivery Note, compare rates, print a label, and then confirm that the AWB number and tracking status update on the Shipment as expected. Also decide who corrects a Shipment when the carrier shows a different status from the warehouse record, and whether that correction is made in ERPNext, at the provider, or in both places. ERPNext Shipment documentation lists the fields to review against your own process.
How shipment fields map to ERPNext documents
This table maps the data a shipment needs (items, weights, consignee, carrier, tracking) from ERPNext documents to the Shipment document and to the equivalent fields at SendCloud and LetMeShip. Use it to scope the integration and to list the fields your team must confirm with each provider before go-live, since unit and country code conventions are where mismatches usually appear.
| Data element | ERPNext source and Shipment field | Provider equivalent and what to confirm |
|---|---|---|
| Items and quantities | Delivery Note items feed the Shipment (linked to the Delivery Note); confirm which item rows are packed together | Parcel contents or order lines at each provider; confirm whether the provider requires item-level declarations for your destinations |
| Weights and dimensions | Item weight and package dimensions from the Item master or Shipment parcel entries; confirm the unit of measure stored in ERPNext | Parcel weight and size fields; confirm whether each provider expects kilograms or grams and centimeters or other units |
| Consignee address | Shipping address on the Delivery Note, copied into the Shipment delivery address fields | Recipient address block; confirm line-length limits, postal code formats and required state or region fields by country |
| Country codes | Country link field on the address; ERPNext stores country names, so confirm the mapping to ISO-style codes | Destination country code expected by each provider; confirm the code standard used in the connector mapping |
| Customer and contact data | Customer and Contact records linked to the Delivery Note, used for recipient name, phone and email | Recipient contact fields; confirm which phone and email fields are mandatory and how the provider uses them in notifications |
| Carrier and service selection | Shipment carrier and service level chosen from the rate comparison in the ERPNext Shipping app | Carrier and service identifiers in each provider account; confirm which carriers and services your account can book in each country |
| AWB number | AWB number stored on the Shipment document after label creation | Tracking or label number returned by the provider; confirm where the provider returns it and whether it can be reprinted |
| Shipment status | Status on the Shipment document, updated by tracking | Status events at each provider; confirm which events map to delivered, in transit or exception and how often updates arrive |
Protecting API keys and shipping data
Shipping touches carrier credentials and consignee personal data, so access has to be designed before labels start printing. The cards below cover where keys live, who can create or void shipments, who can change rules, how consignee data is handled, and how carrier accounts are scoped.
Store each provider API key restrictively
The ERPNext Shipping app needs a separate API key for LetMeShip and for SendCloud, and each one lets its holder create shipments and print labels under your account. Keep both keys out of shared documents and screenshots, limit read access on the settings record to a small administrator group, and record who rotated each key and when. Confirm with each provider how keys are issued, whether they can be scoped or revoked individually, and what their support process is for a suspected leak.
Limit who can create or void shipments
A Shipment is tied to a Delivery Note and carries the AWB number, carrier and status, so creating or cancelling one changes what the carrier and your customer see. Use ERPNext role permissions to separate users who prepare shipments from those who can cancel them, and review that voiding a shipment is not available to general sales or warehouse roles. Check how a cancelled label is treated by each carrier before you grant that right.
Review who can edit shipping rules
Shipping Rules and carrier selection decide which provider and service a Delivery Note uses and what shipping charge a customer sees. A change here can silently send parcels through a more expensive service or the wrong carrier account. Restrict edit rights on these records to the team that owns shipping costs, and keep a dated log of rate and rule changes so finance can trace a surprising charge back to its source.
Handle consignee data under your privacy policy
Each shipment sends a consignee's name, address, phone and email to the carrier, which makes the carrier a recipient of personal data in its own right. Document the purpose and legal basis for that transfer in your privacy notice, check the data processing terms each carrier offers, and decide how long shipment records and label images stay in ERPNext. Confirm with your privacy lead whether print logs and tracking emails need the same retention rule.
Scope provider accounts to required permissions
Carrier accounts often offer more capability than label printing and tracking need, such as account settings, billing views or address book management. Ask each provider whether the account or API key can be limited to shipment creation and tracking, and create a dedicated login for this integration rather than reusing a person's account. Review the account's users and access every quarter and when staff leave.
Common shipping integration failures and fixes
This table lists the failures teams most often hit when wiring ERPNext Shipping to SendCloud or LetMeShip, with the likely cause, the check to run and the fix for each. Work down the rows in order, because a rejected API key or missing address data blocks every later step.
| Failure | Likely cause | Check and fix |
|---|---|---|
| API key rejected | The key was copied with extra spaces, belongs to a test or sandbox account, or was entered under the wrong carrier in the Shipping settings. | Re-enter the key for the carrier you use, save, and confirm the account in the provider dashboard. Ask the carrier which key type ERPNext expects. |
| No rates returned for a destination | The destination country or postcode is outside the services enabled on your carrier account, or the Shipment has no weight or dimensions to rate against. | Check the carrier's enabled routes for that country, then confirm the weight and package size on the Shipment. Test one known domestic and one international address to isolate the cause. |
| Label creation blocked by missing data | Weight, consignee phone or email, street address or postcode is empty on the Delivery Note, customer address or item master. | Fill the missing fields on the source Delivery Note and linked address, then regenerate the label. Ask the carrier which fields it treats as mandatory for your lanes. |
| Label exists at the provider but not in ERPNext | The provider created the shipment, but the response failed or timed out before ERPNext saved the AWB number and label to the Shipment document. | Search the provider dashboard by order reference, then check the Shipment for a saved AWB. Attach the label manually or re-sync if the connector supports it, and confirm with the carrier before reprinting. |
| Tracking status not updating | The scheduled status refresh has not run, the carrier API limits or delays updates, or the AWB number was saved with a typo. | Compare the AWB number on the Shipment with the carrier record, then trigger a manual status refresh. Confirm with the provider how often tracking events are published for your service. |
| Duplicate shipments after retries | A user or background job re-submitted a Shipment after a timeout, so the carrier created a second label for the same order. | Check the provider dashboard for two labels with one reference. Cancel the extra label with the carrier, keep one AWB on the Shipment, and ask the vendor whether repeated submissions are guarded against. |
Questions buyers ask before connecting shipping
What drives the cost of connecting ERPNext to SendCloud or LetMeShip?
The cost comes from four parts: the carrier or provider account fees you pay directly to SendCloud or LetMeShip, the configuration hours to set up API keys, carriers, service levels and the Shipment workflow in ERPNext, any custom carrier logic, and testing time. Provider fees recur and vary by plan and volume, so check the current figures on each provider's pricing page rather than relying on estimates. Configuration is largely one-time, while the provider subscription and label costs recur. Ask any partner for a quote that separates these components and states which carriers and warehouses are in scope.
Can our team set up ERPNext shipping without a partner?
Often yes, if you have someone comfortable with ERPNext's Delivery Note and Shipment documents and with the API credentials each provider issues. The ERPNext Shipping app compares rates across providers, generates labels and tracks status, and both the LetMeShip and SendCloud integrations need an API key, so the core setup is within reach of an experienced ERPNext administrator. A partner adds value when you need multiple warehouses, custom rules, or a cutover with live orders. Decide based on your team's ERPNext depth and how many people can test before go-live.
How long does testing take with several carriers and high order volume?
Testing time grows with the number of carriers, service levels, countries, and order types you need to cover, so there is no fixed duration that applies to every business. Plan separate test runs for rate comparison, label printing, tracking updates, and returns, and test each carrier against realistic order sizes and destinations. Use the provider's test or sandbox environment where it is offered, and confirm with each provider which test options your account includes. Ask any partner to show the test matrix in the written scope before work starts.
What do operations and finance staff need to do for shipping?
Operations staff need to define carrier rules, warehouse ownership, packing and label workflows, and how exceptions such as failed deliveries or address errors are handled. Finance staff need to confirm how shipping charges map to income or expense accounts and how carrier invoices reconcile against Shipment records. Both groups should review sample Delivery Notes and tracking data during testing. Their time is usually concentrated in the design and testing phases, then shifts to routine monitoring after go-live.
When do we need a custom app instead of the existing connectors?
Use the existing ERPNext Shipping app and its SendCloud and LetMeShip connectors when your carriers and workflow fit what those integrations already do. Consider a custom app when you need carriers the connectors do not cover, complex routing or cost rules that the standard rate comparison cannot express, or deep integration with a warehouse management system. Confirm the current carrier list and features with the ERPNext documentation before deciding, since the connector scope can change between versions. A custom app adds build, testing and upgrade effort that recurs with each ERPNext release.
Do shipping integrations change our tracking data or customer records?
Shipping data lives on the Shipment document, which tracks the AWB number, shipment status and carrier, and can be created against a Delivery Note or independently. Tracking updates therefore flow into ERPNext records that your sales, support and finance teams may rely on, so decide which fields are authoritative and who can edit them. Review role permissions for Shipment and Delivery Note before go-live, and confirm with your team how returns and corrections should be recorded.
Where should we check the API keys and provider settings before go-live?
Store the SendCloud and LetMeShip API keys in ERPNext's configuration for each provider, not in shared documents, and limit who can view or change them. Confirm each key's permissions and environment (test or live) with the provider, and rotate keys when staff change. Run a live label test on one low-risk order before enabling the integration for all shipments. Ask any implementation partner to document where each key is stored and who holds access.
Testing rates, labels and tracking before go-live
Before go-live, prove the full shipping loop on a staging copy of the site: rate comparison, label generation, AWB capture and status updates. Start by confirming with SendCloud and LetMeShip which test or sandbox environments each offers, whether test API keys are issued separately from production keys, and whether test shipments create billable labels or carrier pickups. Those answers decide whether you can test end to end or only in parts, and they belong in the project plan before any Delivery Note is touched. Keep the ERPNext Shipping settings and the API key for each provider in a staging-only configuration so that no test shipment reaches a live carrier account by accident.
Build a set of sample Delivery Notes that covers the cases your business actually ships: a domestic address, an EU or other cross-border address, a parcel above and below your weight thresholds, a multi-package order if you use it, and a destination that a carrier refuses or flags. For each one, compare the rates returned by the Shipping app with the carrier's own quote, check that the chosen service and package dimensions match what was expected, and generate a label. Open the printed label and the Shipment document side by side and confirm that the AWB number, carrier and shipment status were written back to the Shipment record linked to the Delivery Note. Then trigger a status update from the carrier or a test event and confirm the Shipment status changes as expected.
Write the rollback steps before the first live order. Record which Shipment documents, Delivery Note fields and stock entries a failed or cancelled test creates, and decide who may cancel a Shipment and how a wrongly created label is voided with the carrier. Keep a short checklist for the cutover day that disables the staging keys, switches to production keys, and confirms that only the intended users hold the Shipping permissions. Because test results depend on each provider's environment, record which steps were verified in a sandbox and which only on live accounts, and retest any gap before you rely on it.
How DeployOpen scopes and supports ERPNext shipping work
DeployOpen plans, implements, tests, documents and supports ERPNext shipping integration with SendCloud and LetMeShip inside your own infrastructure. Each engagement starts from a written scope that fixes what the Shipment and carrier setup will cover before any build work begins.
How we scope
- Confirm which carriers, services and countries your shipping lanes actually use before choosing SendCloud, LetMeShip or both.
- Map which Delivery Notes create Shipments and which shipments are created independently, with the status flow each needs.
- Agree in writing how label printing, AWB capture and tracking updates will work at your dispatch points and warehouses.
How we build
- Install the ERPNext Shipping app and configure each carrier connector with API keys stored under your own credential handling.
- Set up Shipment rules, default packaging and service mappings, then test rate comparison against real sample orders from your catalogue.
- Test label generation, tracking status updates and error handling on a staging site before any change reaches live operations.
How we hand over
- Deliver written configuration records covering carrier accounts, API key ownership, Shipment statuses and print settings.
- Document the dispatch procedure, the exception steps for failed label requests and the roles allowed to create or cancel Shipments.
- Walk your operations and IT staff through the runbook and confirm who receives carrier and connector error notices.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer, covering changes to carrier APIs or ERPNext releases.
- Review connector behaviour after each ERPNext minor release and retest label printing and tracking before rollout to production.
- Confirm with your carriers and connector vendors which API keys, account terms and service levels apply to your account.
