What the spam block status in a delivery means

Service information from the supplier of the batch may arrive in the delivery together with the credentials, and the spam block status is one of those values. In raw form it is a number that tells the buyer nothing on its own, which is why the delivery decodes it into words. The field has several states, and confusing them is expensive.

The first five values are state codes, the last two are time. That is exactly why the decoding is needed: in raw form −3 and −4 look almost the same while meaning different things, and telling a code from a date by eye does not work either.

The status does not arrive with every position: this is supplier data, and where the supplier did not pass it on, the state stays unknown. An empty field reads the same as «not checked» — as an absence of information rather than a good version of it.

The field itself refers to the moment of delivery, not to the moment when you opened the order. That matters for reading the last row of the table: a date in the past means the restriction existed and ended, not that it is about to begin.

This is the most frequent reading mistake. The state «not checked» means exactly one thing: nobody looked. It asserts neither the presence of a restriction nor its absence, and reading it in your own favour is not allowed. If the status is critical for your task, pick positions where it is filled in, or check the batch yourself inside the thirty-minute window.

The opposite situation occurs as well: the field shows a date and it has already passed. That is the «lifted» state — the restriction existed but its term expired. A date in the past is not a sign of a problem here but a sign that the problem is over.

Checking the state on your own inside the window is hard: a restriction shows up on an action rather than on the login, and thirty minutes are not enough for such a check. So the status in the delivery is not a duplicate of your own check but the only signal available at hand-over.

The difference between «not checked» and «no spam block» costs money. The first is an absence of information, the second is the result of a check. Positions have to be picked by the second one, not by the fact that no bad news is visible in the field.

The shop guarantee answers for the account matching the position description at the moment of delivery and for the completeness of the data handed over. The spam block status is part of that data, so it has to be checked in the same place as the login: within thirty minutes of the purchase.

• Look at the status straight away rather than after the load into your software — the replacement window is counted from the moment of purchase.
• A spam block and login validity are different things: an account may let you in and still carry an action restriction.
• The shop states plainly that it does not guarantee account behaviour after hand-over: what happens next depends on how the account is used.
• If the data does not match the position description — the support bot, the order number, the SKU.

The most convenient way to read the status is together with the composition of the line: both are visible right in the delivery and require no login into the account. The login is needed to check validity, while the contents and the restriction are read earlier and faster.

An important detail about terms: a restriction with a date in the future is not cancelled by the fact that you logged in. It will simply expire on the stated day. The guarantee answers for the data matching the position card, not for the restriction being absent altogether.

The practical conclusion is simple: the spam block status is to be accounted for in planning rather than overcome. An account restricted until a specific date is worth putting aside until that date instead of being worked with at once — load during a restriction period ends in nothing good.

• A date in the future — the position is logically postponed until that day and not warmed up earlier.
• «Permanent spam block» — a state with no term: counting on it being lifted is not worth it at all.
• «Spam block lifted» — the restriction existed and ended; at hand-over this is a normal state.
• «Not checked» — plan as if the state were unknown, because it is unknown.

Planning by status is simpler than it seems: it splits the batch into three baskets — work now, postpone until a date, do not count on at all. Sorting the lines into baskets at hand-over is cheaper than discovering a restriction halfway through the load.

Separately worth remembering is the category with the FROZEN mark: there the state of the account is declared right in the position title and priced in. It is not the same thing as a spam block, but the logic is the same — a property of the product known before the purchase, not a defect.

More data arrives from the supplier with the batch than the buyer sees. Part of the fields is cut off deliberately, before the line reaches the order, and that is not a loss of information but a filter: what goes into the delivery is what relates to the account, not to the internal kitchen of procurement.

• «success» — a service flag of the response from the supplier system.
• «raw» and «raw_item» — the supplier's whole response in unprocessed form.
• «item_id» — the internal number of the position on the supplier side.
• «price» — the supplier's service price field; you see the price on the shop card.

This filter is worth knowing about for one reason. If you compare the line you received with what you saw at the supplier elsewhere, the field sets will not match — and that is expected. The missing fields did not get lost, they are simply not about your account.

The public API returns the same set of fields: there are no supplier service flags in the catalogue response. A script written from the documentation will see exactly what a buyer sees in the account panel — the composition of the delivery does not depend on the way of buying.

At hand-over one simple rule follows: do not look in the delivery for fields that never occur there. Everything about the account is the credentials in the format stated in the title, plus the spam block status. A divergence from that set is a reason to write to support: the order number, the position SKU and which field was missing.