FulfillVia platform
Platform capabilities
What the FulfillVia control plane does today, area by area. Each area below is a workspace that exists in the operations console and is gated by a named permission — this is the delivered surface, not a roadmap.
Inventory control
Stock is an append-only ledger per tenant, facility, location and SKU. On-hand and available-to-promise are derived from the ledger, so every balance reconciles back to the entries that produced it — there is no counter for someone to overwrite.
Ledger, adjustments and conditions
Adjustments post with a reference, an idempotency key and a request fingerprint. Stock is held by condition — sellable, damaged, quarantined, expired or in transit — so unsellable units never quietly count as supply.
Reservations and available-to-promise
Reservations move through active, confirmed, partially released, released, expired and shipped, with consumed and released quantities tracked separately. Availability is quoted as ledger minus live reservations, and expired reservations are swept automatically.
Lot, serial and expiry traceability
Lot numbers, expiry dates and serial units are first-class stock identity. Per-SKU handling requirements declare whether lot, serial or expiry capture is mandatory, alongside dangerous-goods, temperature range, oversized and special-equipment attributes.
Trace-aware cycle counts
Counts default to blind. Worksheets capture lot and serial detail, submission and approval are separate permissions held by different people, and an approver can require a governed recount instead of accepting a variance.
Recall and quarantine
A recall case names its severity and traced lots or serials; activating it quarantines that stock and shows the demands and shipments already affected and the quantity consumed. Every transition records the actor and reason.
Expiry enforcement
Lots past their expiry date are reclassified out of sellable stock, and SKUs can require a minimum remaining shelf life before a lot is eligible to be picked.
Event delivery back to commerce
Inventory changes publish through a transactional outbox with pending, enqueued, delivered, failed and dead-lettered states, attempt counts and backoff — and an operator replay for anything that got stuck.
Warehouse execution
A handheld-first workspace for the people on the floor. Operators are scoped to their assigned facilities, and every scan is evidence.
Directed pick and pack work
Pick tasks name the location, SKU and requested quantity, carry an explicit pick authority and a version, and are confirmed against the task as issued — two devices cannot silently confirm the same pick.
Real barcode handling
GS1-128, GS1 DataMatrix and GS1 QR are parsed into GTIN, lot, expiry and serial. Resolution is reported as a match, no match or ambiguous, with the reason — an unreadable label is never guessed at.
Trace capture at the scan
Where a SKU is lot or serial controlled, the picking context is the authority on what may be selected, and the trace detail is captured as part of the confirmation rather than reconstructed afterwards.
Short picks go to a supervisor
A scanner-confirmed short pick cannot be resolved by the operator who raised it. Resolution is a separate supervisory permission with its own record.
Every scan is measured
Scan attempts — successful or not — are persisted as observations, which is what the scan-success service objective is actually computed from.
Works through dead zones
The console caches its own shell through a service worker, so it keeps loading in a warehouse with patchy coverage. Live operational data is deliberately never cached, and actions that change warehouse state pause while offline.
Order fulfillment lifecycle
Demand arrives from the connected commerce platform as a signed, versioned snapshot and is driven through explicit state machines. Illegal transitions are rejected; replays of the same state are idempotent.
Governed demand states
Demand moves through ready-to-allocate, on hold, allocated or partially allocated, external fulfillment, ready-to-pick, picking, picked, packing, packed, partially shipped, shipped and cancelled — as a defined graph, not as free-text status.
Atomic allocation
Allocating a demand reserves the inventory for its plan in a single transaction, so a plan is either fully reserved or not reserved at all.
Release, pick, pack, dispatch
Release to pick, confirm picks, pack cartons and dispatch shipments are separate commands with separate permissions, each appending to the demand history.
Full demand history
Every state change on a demand is retained with its actor and cause, so the question "why did this order do that" has an answer that does not require reading logs.
Carrier shipping and the provider network
Adapters for EasyPost, Shippo, UPS and the Digitrend Logistics Marketplace sit behind one contract, so rating, buying, tracking and voiding a label look the same regardless of who carries it. A connection has to earn and keep the right to be used.
Rate shopping with lineage
A rate shop fans out across connections and scores quotes on price, speed, guarantee and preference, with hard gates for a maximum amount, a required guarantee, a deliver-by deadline or a currency mismatch. The eligible quotes, the excluded quotes with their reason, and the providers that failed are all retained.
Labels, documents and print
Labels are produced as PDF, PNG or ZPL, with manifests, shipment documents and scheduled pickups. Warehouse printers register as devices, heartbeat, and claim print jobs under a lease; artifact downloads are checksum-stamped and never cached.
Certification before traffic
A connection must pass a live sandbox certification whose full report is stored and hashed, and hold it under a validity policy — 90 days by default, with recertification due 14 days ahead. Production credentials are promoted only after a non-mutating probe verifies them.
Per-provider circuit breaking
Each connection has an operational policy: requests per minute, an hourly retry budget, a service-level window, a minimum sample size, a minimum success rate and a target latency. When measured service drops below policy, the circuit opens instead of hammering a degraded carrier.
Tracking and exceptions
Carrier webhooks land in a durable inbox with replay-ID and signature checks and dual-slot secret rotation, with polling as a fallback. Delivery exceptions become tracked records that are acknowledged and resolved by a person, with a note.
Label refunds are money-safe
Void and refund state is reconciled against the carrier. Anything the carrier will not settle automatically goes to a manual review where one person proposes an evidenced disposition and a different person decides it.
Customs and landed cost
Cross-border shipments carry full customs declarations — HS codes, origin country, incoterms, non-delivery instruction and tax identifiers including VAT, IOSS, EORI and GST. Customs holds become cases with an issue code, an SLA due date, broker submissions and an explicit resolution.
Recovery drills
Failover is exercised deliberately: reconciliation, ambiguous outcome, webhook replay and queue recovery must each pass against linked evidence, and a second operator approves the drill.
External and 3PL fulfillment
When demand is fulfilled by someone else, FulfillVia models what each provider can actually do and holds the relationship to the same standard as a carrier. Adapters exist for ShipBob, Shipfusion, ShipHero and ShipMonk.
A real capability model
Each connection carries rate cards, service calendars with blackout dates and time zones, geographic zone sets, and a fulfillment profile: daily order capacity, maximum lines and units, local cutoff time, destination countries, excluded postal prefixes and handling capabilities.
Commercial terms are versioned
Rate cards, calendars and zone sets are versioned with an effective window and a supersession chain, and record where the terms came from. Activating a rate card requires a different permission from authoring it.
Inbound receiving
Warehouse receiving orders are created against a purchase order with package and box packaging types, per-box tracking, and lot, lot-date and serial detail per line; provider status is reconciled back and inventory kept in sync.
Nothing is guessed at
When a provider submission gets a lost response, FulfillVia discovers candidate provider orders rather than resubmitting. One person proposes attaching the order or certifying that it was never created; a second approves. The same pattern covers receiving and returns.
Unidentified receipts
Stock that arrives on the dock without a matching order is recorded with carrier, tracking, package count and photo or document evidence, then associated — or discarded with a reason — through the same propose-and-approve flow.
Governance and offboarding
Consent records for commercial terms, data processing and rate-card terms are append-only and downloadable. Retention policies per data family are drafted by one operator and activated by another, and offboarding a revoked connection needs an independent approval to complete.
Routing and policy simulation
Routing does not just pick a winner — it records why. Every candidate keeps the evidence its score was built from, and a policy can be tried as a pure dry run before it touches live demand.
Evidence-backed decisions
Each candidate records coverage percent, on-time percent with its sample size, capacity used against daily capacity, estimated fee and whether that fee came from a rate card or a flat profile rate, calendar version and expected next service day, zone set version, health, and the exclusions that ruled it out.
Constraints you can express
Policies can require handling capabilities such as dangerous goods, temperature control, lot, serial or expiry tracking, oversized or named special equipment, prefer specific providers, and set a minimum on-time percent or a maximum fulfillment fee.
A genuine dry run
The routing policy simulator is read-only by contract. Supply a scenario and hypothetical candidate evidence, and it reports candidates, eligible candidates, awards and the number of writes a real run would have made — while making none.
Returns, claims and disputes
The reverse path is a first-class part of the platform, not an afterthought bolted onto shipping.
RMA lifecycle
Returns move from requested through authorized, in transit, received and inspected to resolved — or rejected or cancelled — with an RMA number, a merchant reference, a reason code and a resolution of refund, replacement, store credit or no action.
Dispositions write back to stock
Each return line records its condition and a disposition of restock, refurbish, liquidate, dispose or return to vendor, down to the individual lots and serials, and a restock posts back into inventory at a named facility and location.
Carrier claims
Loss, damage, service failure and billing adjustment claims are submitted to the carrier, reconciled on a schedule, and carry requested against approved amounts with their evidence references. Resolving one requires an approval from a second person.
Shipment exceptions
Delivery exceptions carry a severity, a category, the raw carrier status and when it happened, and are worked from open to acknowledged to resolved with a resolution note.
Commerce integration
Tenant provisioning, catalog, order demand and availability requests arrive from the connected commerce platform over a signed, replay-protected event channel, against a registry of versioned contracts. An unregistered event type is rejected, not best-effort parsed.
Signed, replay-protected ingress
Payloads are HMAC-signed over a timestamp and canonical JSON, compared in constant time, accepted only inside a five-minute window, and checked against a replay nonce.
Signing keys with governed rotation
Keys are registered against a secret reference with a validity window, revoked immediately when needed, and every lifecycle change is written to immutable evidence with the actor.
Versioned event contracts
Inbound provisioning, catalog, demand and availability events and the outbound demand, inventory, routing, shipment, returns, shipping and finance events are all registered with a schema version. Each contract declares its data classification, retention class, erasure mode and which fields are personal data.
Durable inbox and outbox
Both directions land in durable stores with attempt counts, backoff and dead-lettering, dispatched by a shared job plane rather than in-request.
Operator visibility and repair
Operators see the provisioning inbox with event ID, type, schema, status, attempts and both occurred and received times; queue health across the retry, dead-letter, recovery and outbox queues; and per-tenant failed, pending and processed counts with mean latency and the oldest unresolved failure. Redrive is available — and audited.
Marketplace finance and governance
A marketplace only works if money settles correctly and disagreements have a process. Finance state is append-only, currency conversion keeps its provenance, and every payment step needs a second person.
Immutable financial ledger
Debits and credits are posted with a posting key, a reference and their evidence, and are never edited. Every downstream figure derives from the ledger.
Three-way invoice match
Provider invoices are ingested line by line and held against what the platform expected, with the variance carried explicitly. An invoice moves from review-required or matched to approved, disputed or settled — nothing settles by default.
Governed disputes
A disputed invoice opens a dispute that accumulates evidence notes and closes on an explicit resolution, rather than being negotiated over email and reconciled from memory.
FX with provenance
Tenant FX rates are versioned to eight decimal places with an effective window and a recorded source. Each settlement pins the rate and version it used and the rounding policy it applied, so a converted amount can always be re-derived.
Payouts need two people
A payout batch is built for a period from its lines, then approved and paid under a separate approval permission from the one that created it.
Deterministic finance exports
Exports are byte-deterministic RFC 4180 CSV with a stable header and a fixed record order, stored with a SHA-256 digest, a retention date and a legal-hold flag. The file a controller reviewed is the file that can be produced again.
Provider SLAs and scorecards
SLA policies set target transit hours, minimum on-time and success rates and a measurement window per service code. Measurements feed both the provider scorecards and the routing decision.
Operations evidence
Service levels are published as data rather than asserted in a slide, and the platform is explicit about which of its own numbers are fully measured and which are only partially covered.
A published SLO catalog
Objectives cover demand acceptance latency, award latency, inventory accuracy, pick accuracy, scan success, on-time dispatch, on-time delivery, notification latency, reconciliation drift, financial variance and provider webhook acceptance — each with its target, unit and comparison direction.
Measured baselines, with their coverage
Baselines are computed per tenant over a 28-day window and report the measured value, the sample size and when it was measured. Each objective declares whether its coverage is fully measured or partial — a claim the platform makes about itself in the open.
Prometheus metrics
Operational series are exposed in Prometheus format: queue depth, inbox and outbox backlogs, oldest unresolved failure ages, rate-limit rejections, approval backlogs, overdue reconciliations, suspended connections and custody command health.
Bounded alert definitions
Webhook alert rules are published with their expression, severity, duration threshold and the operator evidence a responder should collect — including signature failure surges, replayed deliveries and offboarding races.
Redaction before exposure
Telemetry passes through explicit redaction, so personal data and secrets do not leak into logs, metrics or operator views.
Platform foundations
The parts that are not a screen, but decide whether everything above can be trusted.
Multi-tenant by construction
Organizations, facilities, locations and provider connections are tenant-scoped at the data layer. Tenancy is taken from the verified token, never from the request body, and every service call is scoped by it.
Federated identity
Sign-in is delegated to your organization’s identity provider. Tokens are verified against published keys with issuer and audience checks, and FulfillVia never asks for or stores your password.
Authorization fails closed
The API enforces thirty-four named permissions, and a route that declares no policy is refused rather than allowed. Console areas are gated by the same permissions — inventory:read, warehouse:operate, providers:read, integrations:read, finance:read, telemetry:read — on both the route and the API.
Two-person integrity controls
Cycle-count approval, rate-card activation, retention-policy activation, offboarding, payouts, manual refund decisions, claim resolutions and ambiguous-submission resolutions each require a different permission from the person who proposed them.
Idempotency on anything that moves money or stock
Mutating routes take an idempotency key and store it with a fingerprint of the request. A replay returns the original result; a replay with different content is rejected rather than silently executed twice.
Artifact custody
Labels, manifests, shipment documents, evidence and finance exports are content-addressed, stored under object-lock governance with a customer-managed key, and re-verified against their checksum on read. Legal hold, verification, orphan inventory and deletion are all audited actions.
Decimal-safe money
Amounts and quantities are fixed-precision decimals with string arithmetic and an explicit rounding policy. No floating-point money anywhere.
Abuse protection
Rate limits are applied per principal, per provider connection and per signed source, counted atomically with hashed subjects, and are required to be enabled in production.
Accessible by requirement
The console is built to WCAG 2.1 AA and every page is scanned automatically on each change. An accessibility violation fails the build instead of shipping.
Want this running on your network?
FulfillVia is a pilot platform and tenants are onboarded individually — there is no self-service sign-up. Tell us what you fulfill and where from, and we will set up your organization, facilities and identity provider.