How to Migrate Off Bring's Retired 0335 API Code

If your order management system still books Bring's Express Nordic 09.00 (0335), today is the day those requests stop working. Bring quietly retired the product code, and any Booking API call still referencing it will bounce. This is a straightforward Bring API migration, but only if you know exactly which fields to change and where the old code is hiding in your codebase. Here's the full walkthrough, including what happens if you miss the window and how to catch it before your customer service team does.

Why This Migration Can't Wait

On 1 September 2026, Bring is decommissioning the service Express Nordic 09.00 (0335), and strongly recommends transitioning to the alternative service from Bring Courier & Express (3620 + VAS 1171) as soon as possible, as requesting 0335 will not be possible after this date. There's no grace period baked into the API itself. It's a hard cutover, not a gradual sunset.

This isn't an isolated change. Bring has been working through a list of hard-dated deprecations across the Booking and Shipping Guide APIs this year. From 1 July 2026, Bring discontinued the Cargo Insurance additional service (0068), and after that date it's no longer possible to request Cargo Insurance through the Booking API, regardless of customer agreement or booking channel. And earlier in the year, Bring decided to discontinue its own terminal operations in Finland, so services for parcels and pallets sent from Finland were decommissioned from 27 May 2026, with the exception of return services.

If your team maintains its own Bring Booking API integration in-house rather than relying on a TMS that handles carrier connectivity for you, this is exactly the kind of change that slips through the cracks. Nobody owns the developer changelog. Nobody gets an email. You find out when Express Nordic bookings start throwing errors and a warehouse supervisor calls IT.

What You Need Before Starting

Before touching production code, confirm you have the following in place:

• A Mybring user account with an active API key. When you have a Mybring user account, you must create an API key and give the user access to the customer number you want to make action on behalf of.
• Booking API rights specifically enabled on that key. It's a separate toggle from general API access, and if it's off you'll get authentication failures that look like a credentials problem rather than a permissions one.
• Access to Bring's test/sandbox endpoint so you can validate the new product/VAS combination without touching live shipments.
• A full inventory of every place "0335" appears in your stack: order creation logic, rate-shopping calls to the Shipping Guide API, label templates, service-name mapping tables in your ERP or OMS, and any hardcoded fallback logic for failed bookings.

Migrating from 0335 to 3620 + VAS 1171, Step by Step

1. Audit every integration point that books product 0335. Search your codebase and configuration tables for the literal string "0335," not just the human-readable service name "Express Nordic 09.00." Carriers rename display labels far more often than they change codes, so string-matching on the code itself is more reliable.
2. Update the Booking API request payload. Replace the product reference with 3620, then add 1171 to the additionalServices array as its own object. Bring's own documentation on the service portfolio explains that some VAS entries need extra fields like numberOfItems or a usage code, so check the specific requirements for 1171 rather than assuming it's a bare id-only entry. Note also that this VAS requires an agreement in Mybring to be available for booking, so confirm your customer number is actually provisioned for it before you deploy, or every booking will fail with an authorization error instead of a validation one.
3. Verify your authentication headers are correct. Every Bring API call needs the same two headers, formatted exactly as Bring expects: X-Mybring-API-Uid (your Mybring login ID) and X-Mybring-API-Key (your user's API key). This step rarely changes during a product migration, but it's worth confirming now since you're already in the code, and a bad header is the single most common reason a functioning integration suddenly returns 400 errors.
4. Run parallel tests in the sandbox. Send a batch of test bookings using 3620 + 1171 and confirm you get back a valid quote from the Shipping Guide API and a successful booking response with a tracking number. Don't just check for a 200 status. Open the payload and confirm the VAS is actually attached to the shipment, not silently dropped.
5. Re-check price and lead-time behavior. Product 3620 may have different lead-time characteristics than 0335 did, and Bring calculates this dynamically. Providing the actual shipping date in the request is a prerequisite for getting the correct lead times, as the lead time is always calculated from the day and time when the parcel arrives at a Bring terminal. If you skip this field, the Shipping Guide API will default to now, which can quietly produce over-optimistic delivery estimates in checkout.
6. Deploy behind a feature flag or a percentage rollout. Push the change to a small slice of production traffic first, watch booking success rates for 24-48 hours, and only then flip the remaining traffic over. Once you're confident, delete the old 0335 branch entirely rather than leaving it as dead code someone might resurrect during a future refactor.
7. Confirm success. You'll know the migration worked when bookings consistently return a valid shipment ID and tracking number, VAS 1171 shows up on the generated label and manifest, and your error logs stop showing any 400-level responses referencing product 0335.

What Happens If You Don't Migrate in Time

After the cutover, any request still specifying 0335 will simply fail. Bring uses near-identical language across its other 2026 retirements, which gives a good preview of the failure pattern: for the mailbox return product, on September 1, Bring is decommissioning the service Return mailbox parcel (9650), recommending transition to alternative return services in Norway (9350, 9300), as booking of 9650 will not be possible shortly after this date. Same hard stop, same wording, same consequence. Expect a rejected request, not a warning.

The practical mitigation is a pre-flight validation rule sitting in front of your outbound Bring calls: reject or auto-rewrite any request still containing "0335" before it ever reaches Bring's API, rather than finding out in a warehouse when a label fails to print. If you're building this validation layer anyway, extend it to the other retired codes (0068, 9650) at the same time, since the failure mode is identical.

One secondary risk worth flagging during bulk re-testing: if you're re-running large batches of historical orders against the new product/VAS combination, watch your request rate. On the Shipping Guide API, clients exceeding 120 requests per second will be throttled and the response will contain HTTP status code 429, and if your use case requires rates above the limit, Bring asks you to contact them directly for assistance. The Booking API is more conservative still: clients exceeding 18 requests per second will be throttled with the same 429 response, with the same recommendation to contact Bring if you need higher throughput. A batch re-test script that fires requests in a tight loop will hit that ceiling faster than you'd expect.

Why Carriers Keep Doing This

Bring isn't unusual here. Every major Nordic and European carrier runs its own deprecation schedule on its own timeline, published in a changelog that shippers are expected to check themselves. PostNord runs a comparable Booking API for the Swedish market, with its own product codes, its own VAS structure, and its own release cadence. If you integrate with both Bring and PostNord directly, you're maintaining two separate change-monitoring processes, checking two separate developer portals, and mapping two separate sets of product codes into your ERP.

This is precisely the maintenance burden that pushes some shippers toward multi-carrier platforms rather than direct integrations. Providers like nShift, Shipmondo, Sendcloud, EasyPost, ShipStation, AfterShip and Cargoson absorb this mapping work on their end, tracking carrier product and VAS retirements and remapping them behind a stable interface, so a change like 0335's retirement doesn't require you to touch your own booking payloads at all. Cargoson, for example, publishes carrier-specific integration documentation covering exactly these kinds of quirks, product codes and return label handling included, so integrators aren't reverse-engineering them from scratch. The tradeoff is the usual one: less direct control over the payload, less vendor lock-in risk if you build it yourself.

Quick Reference: Bring's 2026 Deprecation Schedule

Next Steps

Don't stop at fixing 0335. Pull up your integration's full list of product codes and cross-check it against Bring's current changelog today, since 0068 and 9650 follow the exact same pattern and the exact same hard-stop behavior. Then set a recurring calendar reminder, monthly is reasonable, to check the Bring developer changelog directly rather than waiting for a booking failure to tell you something changed. If you're managing more than two or three carrier integrations this way, that's usually the point where evaluating a platform that maintains these mappings for you starts to pay for itself.