senn-techSnipcart Shipping API: The Source of Truth
A customer orders goods that have to ship on a pallet. The shipping page quotes one price, the checkout cart quotes another, and the product page has a third number listed. Three systems, three answers to the same question. None of them was obviously wrong, because each one was internally consistent. That's exactly what happened on our own online shop at senn-gruppe.com, and the search for the actual truth led us to a Snipcart API that officially doesn't exist.
The case: four systems, one shipment
The shop runs on Snipcart as a checkout layer on top of a Kirby frontend, headless commerce in its purest form: content lives in the CMS, actual price calculation lives with Snipcart, and neither normally knows anything about the other. That works fine as long as nobody has to maintain the same number in two places. With shipping costs, that wasn't the case: the price appeared on the shipping info page, in the product-detail "shipping information" tab, in the structured-data markup for search engines, and finally in Snipcart itself, which is what actually charges the customer at checkout. Four places, one number, at least in theory. In practice, the page had drifted out of sync with what the cart actually demanded for months.
This isn't a Snipcart-specific problem, it's the underlying risk of any architecture that separates content from commerce logic: nothing in the system forces the two sides to agree. A CMS editor changes a number on the page without knowing that Snipcart keeps its own, independent copy. And the reverse holds too.
The shipping architecture the website doesn't show
Before we could fix the discrepancy, we first had to understand how complicated our own shipping logic actually is. The answer: considerably more than the website suggests. Our shop maintains 15 shipping methods in total: two classic, weight-bracketed parcel methods for domestic and neighboring-country orders, with brackets running into the hundreds of kilograms and a minimum order value, plus thirteen more methods for pallet freight, staggered by delivery zone and weight up to several hundred kilograms per pallet. The website normally only explains the first category in detail, because it covers the typical purchase. The second exists for the business with larger, palletized volumes and has to be exactly as correct, even though hardly anyone reads it before placing an order.
Checking that complexity by hand in the Snipcart dashboard (opening 15 methods one by one, comparing brackets, cross-checking values) is exactly the kind of task where a human stops being reliable after the fifth method. So we asked ourselves whether there was a way to read the actually active configuration by machine instead.
An API nobody documents
There is one. Snipcart officially publishes only its checkout SDK and order webhooks, but GET https://app.snipcart.com/api/shipping_methods returns, authenticated via HTTP Basic Auth with the secret key as the username and an empty password, the complete list of all active methods including their weight brackets in grams. The same endpoint also accepts a PUT against a single method ID with the full method JSON and applies the change immediately, no detour through the dashboard required. The path appears in no official Snipcart documentation; other spellings return 404, and a request without a valid key returns 401. Together, that's about as reliable a proof as you get for a real but unadvertised endpoint.
The practical value isn't bypassing the dashboard, it's repeatability: a single GET call shows in seconds what Snipcart is actually charging across all 15 methods, machine-readable and diffable against the previous version. That turns a manual visual check into one line of code you can rerun any time you have doubts.
Merchant Center as the tiebreaker
That solved the technical read access, but not the real question: when two numbers are circulating (an older one on the page, a newer one in Snipcart), which one is correct? The answer didn't come from the shop itself, but from outside: Google Merchant Center, which carries the active shipping configuration (shippingSettings) via the Merchant API that Google Shopping ads and organic product search actually rely on. Nobody can afford to have that number wrong by accident, since it's shown directly to customers in Google search results and a mismatch can lead to ad account suspensions.
A live query against the Merchant API for our own account showed clearly which of the two numbers circulating in the shop matched what Google had known about us for a long time, and therefore which version the website and Snipcart should actually be showing. That was the insight that resolved the case: in a multi-system architecture, the most recently changed number isn't automatically the correct one. The correct number is the one an external system relies on, one that can't afford to get it wrong.
The reconciliation as a process, not a one-off
What came out of the incident is a sequence we now apply to every shipping change: first query Merchant Center via its API (the external truth), then cross-check Snipcart via GET (what the checkout is currently charging), correct any mismatch via PUT, then update the handful of CMS text blocks that repeat the same number in prose, flush the site cache, and finally verify via API one more time that all four places agree again. Every single step is trivial; the sequence is the part that prevents the drift from coming back.
What this means for a client's own shop
The lesson isn't limited to Snipcart or to shipping costs. Once a shop consists of several independent systems (content management, checkout provider, ad feed, structured data for search engines), a mismatch between them isn't a question of whether, only of when. Two things pay off in every shop project we set up: first, a deliberate decision about which system wins in case of doubt, instead of leaving that implicitly to whoever edited it last; second, hunting down a programmatic read path into every system involved, documented or not, because that's what turns a mismatch into something visible within minutes instead of at the next customer complaint. And anyone who ships larger, palletized shipments alongside parcels should plan the shipping logic for that complexity from day one. Retrofitting it into an existing system later is exactly the moment where the page and the cart start to disagree.
Conclusion
Four systems, one number, and in the end an undocumented API and an external data feed helped us figure out which one was actually correct. That's the difference between a shop that just about works and one whose shipping costs are verifiably right, and that kind of integration work is exactly what we offer for websites and online shops: building and wiring up systems so they don't quietly contradict each other.
Further sources
What is special about the Snipcart shipping API?+
Snipcart publicly documents only its checkout SDK, not the management of shipping methods itself. There is a working endpoint though, GET and PUT on /api/shipping_methods, authenticated with the secret key as the Basic Auth username, that returns or accepts the full method list including weight brackets. It appears in no official documentation, yet it responds correctly to both valid and invalid requests. It exists, it just isn't advertised.
Why is Google Merchant Center the source of truth instead of the website itself?+
Because a website page only shows whatever someone last typed into it, while Merchant Center carries the shipping terms that actually reach customers in Google Shopping ads and organic product search. A mismatch there doesn't just cost trust, Google itself treats it as a policy violation. That makes the merchant feed the value every other system has to be checked against, not the other way round.
How many shipping methods does a shop really need?+
Once a shop ships palletized freight alongside parcels, a single flat rate stops being enough. Our own shop runs 15 methods: two weight-bracketed parcel methods for the usual order sizes, and thirteen more, staggered by delivery zone, for pallet freight running into several hundred kilograms. The website usually only explains the first category in detail, because it covers the common case. The second exists for the business with larger, palletized volumes and has to be just as correct, even though almost nobody reads it before ordering.
How do you generally avoid shipping-rate drift in a headless shop?+
By deciding which system carries the truth, and then checking the remaining places (the product page, the info page, structured data, the ad feed) against it automatically and regularly, instead of maintaining each one by hand independently. A single read call to an API is often enough to catch a mismatch within minutes instead of waiting for the next customer complaint.