The Amrod API, in practice

Amrod publishes documentation as a Postman collection, and it is accurate as far as it goes. What follows is the rest: the behaviour you only meet once real data is moving, and the decisions that behaviour forces.

Everything here was established against live data. Where a figure is quoted it was measured, and the catalogue it was measured on held 4 252 products across 25 019 variations.

Authentication

You post a username, a password and a customer code to the identity service and receive a JWT. Every other call carries it as a bearer token against the vendor API base.

Two things matter operationally.

Tokens last an hour. Cache the token and reuse it. Fetch a new one when it expires or when a call comes back unauthorised. Requesting a fresh token per call works and is wasteful.

A failed login tells you which of three things is wrong: the user was not found, the password or customer code is incorrect, or API access is not enabled on the account. The third means your credentials are perfectly good and the account simply lacks permission. No amount of code fixes it. Getting API access approved covers that.

One operational warning worth more than the rest of this section. These credentials are usually shared with the login your staff use on Amrod's trade site. A routine password reset stops the integration silently, leaving the last good data in place and everything looking normal. Ask Amrod for a dedicated API user, and alert on sync failure.

The endpoints, and how big they are

Every module follows the same shape: a full endpoint, and usually a changes-only variant. Sizes measured on a full catalogue:

Change endpoints return the last 24 hours with an action type against each record: created, updated or removed.

There is no pagination, and that decides your architecture

No paging, no filtering, no search. Every endpoint returns everything, and the largest response is around 55 MB.

One consequence follows, and it is not a preference. You cannot call this API while a page is loading. You ingest into your own database on a schedule and serve pages from that. Any design that reaches for the supplier at render time will be slow at best and down at worst.

A second consequence: decode a 55 MB response in one call and PHP will exhaust its memory on ordinary hosting. Stream the response to disk, then parse it incrementally, and memory stays flat no matter how large the catalogue grows.

The daily blackout window

Between 00:00 and 01:00 South African time the API returns HTTP 204 with no content while Amrod prepares data.

204 is a success. Code that only checks for errors will sail past it holding an empty result, and if that empty result is treated as the new truth it will empty your catalogue.

Two rules. Treat 204 as a clean no-op that changes nothing. And never schedule a job inside that hour, because it is guaranteed to find nothing.

Prices and stock join on the variant code. Never the base code

This is the single most important rule in the integration, and getting it wrong produces a catalogue that looks right and is wrong.

The catalogue has two levels. A base product is the parent: it carries the description, the images, the branding options and the category assignments, and it is not purchasable. A variant is the actual sellable item, a specific colour in a specific size. Two code types go with them, a simple code for the base and a full code for the variant.

Prices and stock are published against the variant full code. Join them on the base code and every size of a shirt shows the same stock number. The site looks completely normal, and it is lying to every customer.

Verify the join across the whole catalogue before building anything on top of it. On the catalogue measured here, 25 510 variant codes produced 25 508 price matches and 25 510 stock matches. The two products without prices are genuinely absent from the source and should be handled rather than allowed to stop the import.

Stock arrives at several aggregation levels, and only one is usable

The stock feed tags each row with a stockType.

Use an aggregate for availability and you will show the same number against every size, which is the same failure as joining on the wrong code arriving by a different route.

Note stockType 3. It is in the data and not in the documentation, which is the general lesson: tolerate values you were not told about instead of assuming the documentation is complete.

Decoupled products, and the identifier collision they cause

Amrod sometimes splits a single colour out of a product into a product of its own, typically for clearance or end of line. It gets its own code, its own price and its own branding options.

On the catalogue measured here, 792 of 4 252 products, about 19%, were decoupled.

Ignore them and clearance stock quietly merges back into full-price products and gets quoted at the wrong price.

There is a second, sharper problem. A decoupled product's code can be identical to a variant code belonging to the product it was split from. Assign identifiers defensively: try the plain code, fall back to a suffixed form, and never let a collision stop the import.

Images are resized by editing the URL

Images are published at 1024X1024. Other sizes come from substituting the dimensions inside the URL string. The available sizes are 151X141, 460X350, 46X45, 260X250 and 270X150.

The X is uppercase and the substitution is case sensitive. There is no full-resolution original.

Do not download them. They are served from Amrod's own image servers. Copying tens of thousands of files into your site's media library consumes your hosting's file allowance, adds hours to every import, and buys nothing. Reference the URLs.

Full refresh beats incremental, and the numbers say so

The change endpoints hold 24 hours. Miss a day and that day's changes are gone for good, and you need a full resync anyway.

Since a complete pull of every endpoint finishes in under fifteen seconds, running a full sync nightly is simpler and safer than depending on those windows. It removes a whole class of silent drift, and a missed night corrects itself the following night.

Measure your own payloads before designing around incremental updates. Full refresh is very often simpler, safer and fast enough.

Land the data in your own tables first

Do not write supplier data straight into your shop. Land it in staging tables, then promote it in a separate step.

Four reasons, all of which come up in practice.

• A failed sync cannot damage the live catalogue. The site keeps serving the last good data.
• The supplier publishes more than a shop can model. Branding positions, print methods, colour exclusions, quantity price bands and incoming stock dates have no home in a normal product record, and staging keeps them.
• Change detection gets cheap. Store a hash of each product's source data and skip anything unchanged. A nightly run where nothing changed finishes in seconds instead of minutes.
• Stock can stay out of the shop's own tables. Writing 25 000 stock values into product records every fifteen minutes is a lot of churn for no benefit. Read stock from staging when the page renders instead.

VAT rounding

Prices arrive excluding VAT. Amrod documents a specific rounding sequence, and following it avoids one-cent disagreements between your website and the supplier invoice.

Round the price to two decimals. Add VAT. Round again to two decimals. Multiply by quantity, then round once more.

Before you build anything on top

• Confirm in writing whether an order endpoint exists. It does not, and getting that on the record shapes the whole design.
• Check your host can reach the API at all. Some shared hosts block outbound requests.
• Pull every endpoint once and record sizes, times and row counts.
• Verify the price and stock join on the variant code, across the whole catalogue, and record the match rate.
• Count the decoupled products.

Do not proceed until the join rate is verified. Everything downstream depends on it.

Questions people ask

Can the Amrod API place orders?

No. It is read only. It publishes products, prices, stock, categories, brands and branding data, and has no order-creation endpoint. Orders are placed with Amrod the same way they always were.

Can I request a single product from the Amrod API?

No. There is no pagination, filtering or search. Every endpoint returns its entire dataset in one response, and the largest is roughly 55 MB. You have to ingest into your own database and serve from there.

Why does my Amrod sync return nothing at midnight?

Between 00:00 and 01:00 South African time the API returns HTTP 204 with no content while Amrod prepares data. It is a success response carrying nothing. Treat it as a no-op, and do not let it empty your tables.

Do Amrod prices join on the product code?

On the variant code, never the base product code. Joining on the base code gives every size of a garment the same stock figure, which is the most common and most damaging mistake in this integration.

How do I get different image sizes from Amrod?

By substituting the dimensions inside the URL. Images are published at 1024X1024 and other sizes are obtained by editing the string. The X is uppercase and the substitution is case sensitive.