Shipping and fulfilment

Fylogic has no public API playbook. That is not a reason to skip this page

Fylogic is a Dutch fulfilment party, smaller than Monta and without the same public documentation or install base. That is not a knock on them — plenty of fulfilment operations this size run a perfectly solid warehouse — it just means we cannot describe their API the way we can describe Sendcloud's, because we have not built dozens of connections against it.

What we can tell you plainly: a connection to Fylogic is possible, the shape of it depends entirely on what they are willing and able to expose to you as a client, and the honest first step is a short technical conversation with them, not a quote based on assumptions.

  • API, EDI or scheduled export — depends on Fylogic
  • A short technical check before any quote
  • From €1,700 plus service fees
The tool

What we actually know about connecting to Fylogic

Fylogic operates as a fulfilment partner in roughly the same shape as Monta: they hold your stock, pick and pack orders, and hand parcels to a carrier. What differs is scale and the maturity of the tooling around it — a smaller operation is more likely to offer a data exchange built around what their own clients have asked for than a documented, self-service developer API.

That can mean a REST API, it can mean structured file exchange over EDI or SFTP, and it can mean an export on a schedule that a connection has to be built around rather than dictate to. We would rather say that plainly than promise a shape of integration we have not seen work in practice.

What goes wrong

Three things that go wrong when nobody checks the route first

With a smaller fulfilment partner these are less about the tool and more about the conversation that has to happen before any building starts.

A quote gets written before anyone asks Fylogic what is actually possible

It is tempting to quote a Fylogic connection the same way as a Monta one, because the two look similar from a distance. Then it turns out Fylogic's export runs once a day as a CSV over SFTP, not a live API, and the whole shape of the project — and the price — was wrong from the first sentence.

What you see instead

We talk to Fylogic, or ask you to put us in touch with whoever manages your account there, before we put a number on anything. What they can actually offer decides the plan, not what a similar-looking competitor offers.

A daily export is treated like a live connection, and the site lies for a day at a time

If the only data route is a once-a-day file, a shop that shows it as live, real-time stock is making a promise the connection cannot keep. An item sold out at nine in the morning still shows as available until the next file lands, hours later.

What you see instead

The shop is built around the real frequency of the data, with an honest buffer on anything that moves fast, instead of a stock number that looks live and is not.

Nobody at Fylogic is briefed on what the connection expects, so it breaks at the first format change

A smaller partner with no dedicated integration team is more likely to change a file layout or a field name without announcing it the way a large SaaS vendor would, because there is no changelog and no deprecation notice to read.

What you see instead

The connection validates what it receives and raises an alert the moment a field is missing or a format has changed, instead of silently processing garbage or silently processing nothing.

The bill for doing it by hand

What we can say about cost here, honestly

We are not going to invent arithmetic for a system we have not measured. What we can say is the general pattern that holds for any smaller fulfilment partner: a manual stock check that fills the gap between what Fylogic has and what the shop shows costs roughly the same fifteen to twenty minutes a day it costs with any warehouse partner, and an oversold item costs whatever expediting the replacement shipment costs.

The number that matters more here is time, not money: a project against an undocumented or lightly documented interface takes longer to scope than one against a public API, because the discovery itself is part of the work rather than something we can read in advance.

What we build

We build the thing on the other end too

For Fylogic specifically, the first deliverable is often a short document nobody asked for: what their interface actually does, written down, so the next person who touches it does not have to rediscover it from scratch.

A connection needs two ends. Plenty of agencies will build you the API call and hand you a JSON payload; that is the easy half. The harder half is what the data lands in — a website, a webshop, a portal your customers log into, an internal tool that replaces a spreadsheet. JKC builds both ends, which is why the connections we build tend to keep working: nothing about the receiving side is a black box to us.

API integrations

The connection itself: authentication, field mapping, rate limits, retries and a queue that survives the other system being down for an hour. Built against the documented API where there is one, and against whatever the vendor really offers where there is not.

Websites

WordPress sites that read from your systems instead of repeating them by hand: a careers page fed by your HR system, a team page that follows your payroll, prices and availability that are the real ones.

Webshops

WooCommerce shops where the order is the last time anyone types it: it becomes an invoice in your accounting package, a label at your carrier, a stock mutation in your warehouse, and a line in your CRM, on its own.

Web applications

When the process does not fit any standard product: a customer portal, a quoting tool, a planning board, a dashboard that reads three systems at once. Built on your data, with your systems as the source instead of a copy of them.

What can be connected

What can probably be connected — pending what Fylogic actually offers

This list has the same shape as any fulfilment partner's, written as what a connection should do rather than a promise about which endpoint delivers it, because that second part is the one thing we check before quoting.

  • Orders sent to Fylogic for picking (out of the tool)

    Whether that arrives as an API call or a file on a schedule, the shop's side of this is the same: an order becomes a request the moment it is placed.

  • Stock levels back into the shop (into the tool)

    At whatever frequency Fylogic's own systems actually allow — daily, hourly, or live — and the shop is built to be honest about which one it is.

  • Shipment confirmation and tracking (into the tool)

    A shipped status and a tracking number, in whatever form Fylogic hands them over, mapped into the shop's own order status.

  • Returns received at the warehouse (into the tool)

    If Fylogic reports this at all — not every smaller fulfilment partner does — as a stock correction and a signal the shop can use to process a refund.

Treat every row here as provisional until we have actually talked to Fylogic about your account. That conversation is the first thing we do, not the last.

How it works

How a connection gets built at JKC

The same four steps every time, whichever tool it is. Nothing here is a workshop you pay for: step one exists because scoping a connection wrong is the single most expensive thing that can happen to it.

  1. 1. We look at what is actually being retyped

    Not "which fields exist" but "which fields does somebody currently move by hand, how often, and what breaks when they get it wrong". Most projects turn out to need two or three flows, not a full two-way sync of everything. That conversation is what keeps the quote where it is.

  2. 2. We pick the route, and say why

    A maintained connector from the vendor, a platform like Make or Zapier, or a custom integration against the API. Cheapest first, not custom first: if a supported plugin does exactly what you need, that is the answer and we will tell you so. Custom is for the cases where the off-the-shelf option would need so much configuring that it becomes the fragile option.

  3. 3. We build it to survive the other system

    Every connection ships with retries, a queue and an idempotency key, so an order that arrives while the other side is down is delivered later rather than lost, and a retry does not create a second invoice. On a test environment first where the vendor offers one, so the first thing your real administration sees is a working connection.

  4. 4. We hand it over with the failure modes written down

    Which alerts you will get, what each one means, what to do about it, and who to call. Plus the credentials in your own name, in your own vault — not in ours. A connection nobody but us can maintain is a connection you do not own.

After it goes live

A connection that fails silently is worse than no connection

This is the part most quotes leave out. A connection that stops working without telling anyone is worse than manual work, because with manual work at least somebody notices when it does not get done. Every connection JKC builds is monitored, and the monitoring is not an upsell — it is in the service fee.

An alert per failed message, not a monthly report

A message that does not get through raises an alert the same hour, with the record it was about. Not a dashboard you have to remember to look at.

Replay, not re-enter

Anything that failed sits in a queue and can be sent again once the cause is fixed, in order. Nobody goes back through yesterday to find the four orders that did not land.

We watch the vendor's changes, so you do not have to

APIs get versioned, deprecated and rate-limited. When a vendor announces a change that affects your connection, adjusting to it is part of the service fee, not a new project.

What it costs

From €1,700, and the biggest variable is who built the other end

Because the interface is not standardised the way a larger platform's is, we start with a short paid technical check before quoting a fixed scope — usually a fraction of a full project — so you are not paying integration rates for us to find out what is possible.

A connection starts from €1,700 plus a monthly service fee, which covers the monitoring, the queue and keeping up with the vendor's API changes. Work outside a fixed scope is €95 per hour.

What moves the number is not the tool — it is how well the system on the other end is known. If JKC built your website, your webshop or your web application, we already know its data model, its edge cases and where its stock numbers really come from, and a connection into it is mostly configuration and testing. If it is a system we have never opened, we start with a short technical check of both sides and quote after that, so you are not paying hourly for us to work out the basics.

Two more things that move it, in our experience more than anything else: whether the tool has a real API or only a CSV export, and whether the sync has to go both ways. One-way is roughly half the work of two-way, because two-way means deciding, per field, which system wins when they disagree — and that decision is the expensive part, not the code.

Questions

Frequently asked questions about connecting Fylogic

No, and we are not going to pretend otherwise. Fylogic does not have the install base that would make a reusable connector worth maintaining, so every connection to them starts closer to first principles.

What we do reuse is everything around the interface — the queue, the retries, the monitoring, the alerting — which is the majority of the engineering either way. The part that is genuinely new each time is small.

Free, 10 minutes

Not sure where the manual hours actually go?

That is what the Growth Scan is for. Ten minutes, no sales call attached: you get back where the double work sits, which connection would pay for itself first, and which one honestly would not.