Direct mail API: How Lob routes orders at scale

Every piece of mail sent through Lob's print and mail API passes through our print delivery network — a set of vetted print partners positioned to fulfill orders within days and handle millions of pieces monthly. But having multiple printers isn't the advantage. Knowing how to distribute work across them is. That's where routing comes in. Our routing system optimizes incoming orders based on factors like:

• Balance traffic across our print partners
• Route orders to the nearest fulfillment location to cut delivery time
• Use higher volumes to reduce per-piece costs

Our Postmasters team — the group responsible for print and mail execution — recently rebuilt our routing system from the ground up. The goal: handle 10x volume spikes, support new routing rules without code changes, and let non-engineers configure routes in minutes. Here's how we did it.

How routing started

Routing at Lob has humble origins. In the very early days, our CEO, Leore, would make daily runs to the local Kinkos to fulfill orders. We onboarded our first print partner and started automating — initially by running a script once a day to programmatically transfer orders.

Asorder volume grew from hundreds to thousands per day, we expanded our partner network. Orders needed to be transferred to partners multiple times a day in order for them to be able to continuously process our orders. The execution of the script was automated, in the form of a set of cron jobs. It would look something like this:

• Every 15 minutes, starting at the 0th minute, transfer all postcards to Partner A that haven't been transferred already
• Every 15 minutes, on the 5th minute, transfer all letters to Partner B that haven't been transferred already

The use of cron to route orders worked, but it wasn't perfect. You might be able to identify that this strategy greedily routes orders. Imagine that we added an additional rule:

• Every 15 minutes, on the 6th minute, transfer all letters to Letter Partner C that haven't been transferred already.

Assuming a constant volume of available letters, this rule would route significantly less letters to Partner C because the second rule would have already routed all letters to Partner B.

This system scaled poorly. Every time we added a print partner for redundancy or new capability, we had to juggle job frequency and maintain an increasingly tangled order of operations. Volume spikes made it worse. Within two years, the routing system had grown into a tangle of interdependent jobs that no one wanted to touch—and no one fully understood.

Rebuilding routing for scale

What we set out to fix

The new system needed to accomplishthree things:

• Cut routing time from minutes to seconds so orders reach print partners faster.
• Let non-engineers configure routing rules without touching code.
• Provide the foundation for algorithmic routing that doesn't require constant manualadjustments.

What the new system needed to handle

The old system made complex routing behavior hard to configure — which meant we couldn't optimize for delivery speed or postage costs. The new system needed to support geographic routing, volume balancing, and partner capacity management without custom code.

Routing would ensure that print partners received orders they were capable of producing. We also understood that routing could be used to manage the volume of orders we sent to our partners. Overloading a partner causes production delays—orders that should ship in 24 hours slip to 48 or 72. Too little volume misses partner daily minimums, which means higher per-piece costs.

Routingalso factors in geography. When destinations are geographically concentrated, drop shipping becomes an option — cutting 1-2 days from delivery. Hitting saturation thresholds in a region qualifies mail for USPS discounts. Geographic routing depends on clean, verified address data. Without accurate destination information, geographic routing doesn't work.

The new routing system needed to handle these use cases and support new ones as they emerged.

How we restructured the architecture

The old cron-based architecture bottlenecked on a single job scheduler that couldn't scale horizontally. The cron jobs were bundling two distinct responsibilities:

• Identifying orders to be routed (outstanding orders)
• Routing outstanding orders

We broke these into separate microservices, each with a focused responsibility. The result: we could add routing capacity during volume spikes without touching the order identification service. If volume doubled overnight, we could add routing workers without touching the upstream service.

How the routing service works

The routing service sits at the core: it accepts incoming orders in real time and routes them to the right print partner based on configured rules.

Each worker follows this process:

1. A worker receives an order from the upstream service that identifies routable orders.
2. The order is evaluated against a series of checks that reduce the set of potential print partners to only the ones that are capable of printing that order.
3. One print partner is chosen and the order is sent to a downstream service for fulfillment.

How the rules language works

Thenew routing engine runs on a custom rules language. The JSON-based language lets non-technical users define routing rules—like splitting volume between partners or routing by mail type—without writing code.

The language defines routing rules by pairing order expectations with partners that satisfy them. Here are two example rules:

1. If an order is a check, has any attachment sheets, and is USPS First Class or UPS Next Day, send 100% of these orders to Partner A
2. If an order is a letter and has a return envelope, send 80% of these orders to Partner A and 20% of these orders to Partner B.

You evaluate an order against a rule to determine which partners could fulfill it. For example, ifyou evaluate a USPS First Class check against the first rule, the potential partner is Partner A. If you evaluate a postcard against the same rule, no partners match.

In the rules language:

How rules are evaluated

Rules are grouped and evaluated in series to handle different use cases. The goal: pick one partner for each order.

Evaluation starts with all partners as potential matches. As you evaluate the order against each rule, the set of potential partners shrinks until one remains.

We provided different ways of grouping rules for greedy and non-greedy evaluation. Capability rules evaluate all rules in the group and union the resulting potential partners. For example, if you evaluate an order against two capability rules and the results are:

‍

The resulting partner from the evaluation of the group is Partner B.

Preference rules evaluate greedily based on rule order in the group.

Combining greedy and non-greedy rule groups lets us express complex routing logic that operators can actually read and modify.

Making routing easier to configure and test

The old routing system was configured through a web application that took3-5 minutes to load — and offered no visibility into how rule changes affected volume distributions. In practice, operators were guessing how rule changes would affect volume—and often guessing wrong.

The new system exposes an API for creating and updating rules—with built-in versioning and validation. Engineering and product built a web GUI that lets operators view, test, and enable rules without risk of breaking production routing.

Testing is built directly into rule creation. Rules can be unit tested to verify they route specific order types to the expected partners before going live. Beyond that, we can simulate historical volume through a new rule set to verify volume splits match expectations—before enabling anything in production.

Now we test assumptions against real data instead of guessing. Instead of guessing how routing would handle daily volume swings, we test against real data and know what to expect.

What we learned and what comes next

Since launch, we've added automated capacity balancing and geographic optimization. We're implementing automated routing to partners with available capacity — cutting production delays and reducing per-piece costs. Next: cutting postage costs by saturating regions for USPS discounts and routing orders to the closest entry point, usingLob's Address Verification API. As USPS moves toward distance-based postage, routing mail to the closest entry point saves money—not just time.

Getting engineers, product, and partner ops aligned on a problem no one fully understood—then building something that handles millions of orders? That's what it takes to solve operational problems at scale.

Interested in working on problems like this? We're hiring!

‍