The shop's public API
Programmatic access to the shop: catalog, stock, balance and orders. You create the key yourself in your account, and a request can be tried right here — the playground fires from your browser.
https://boomly.ac/api/v1There is no api.* subdomain: the base is the relative /api.
How to connect
X-API-Key: <ключ из личного кабинета>
X-Timestamp: 1785312000
X-Signature: hmac_sha256(secret, f'{ts}\n{body}').hex()No more often than
120 requests per minute per address
And no more than
60 requests per minute per key
You create the key and the secret yourself in your account. The signature is only needed for keys that have it switched on.
/v1/healthcurl https://boomly.ac/api/v1/health \ -H "X-API-Key: $KEY"
What comes back
{"status": "ok"}If you paid from the balance and delivery failed
Orders paid via the API from balance are refunded to the balance automatically if delivery fails. There is no auto-refund on the site or in the bot — funds are not charged there, and on failure the refund is made through support.
Try it right here
The response will appear here.
The request goes straight from your browser. The key is never stored on the server.
The key is created in your account. Create a key
The numbers in the response that decide for you
For every position the API returns two different stock numbers and two different minimums. Mixing them up is the most common reason an order assembled by a script fails to go through or takes longer than expected.
| Field | What it means | What it affects |
|---|---|---|
| quantity | total stock of the batch | the storefront shows it in the «In stock» column |
| instant_stock | how much ships from ready stock at once | an order above this number takes longer to assemble |
| min_quantity | the minimum batch declared by the supplier | a reference value |
| min_qty_effective | the shop's actual minimum | the order passes by it and the quantity step equals it |
| sku | the public article number | product page address, repeat purchase, support request |
| id | the internal number | a link by id is redirected permanently to the sku |
The rule is short: plan a purchase by the instant stock and the effective minimum, and reference the sku. The total stock and the supplier minimum are reference values, and none of these numbers are worth caching between runs: the catalog is live.
An order: from the request to the delivered lines
An order is created from an sku and a quantity and immediately gets its own number and status. While the batch is being assembled the status says so; a finished order returns the delivered lines inside the order itself — there is no separate request for the data.
- The quantity is a multiple of the position's effective minimum, not of the one declared by the supplier.
- Payment goes from the balance, so delivery does not wait for a transfer to be confirmed.
- An order paid through the API from the balance returns the money to the balance by itself if delivery fails. On the site and in the bot it works differently: there the funds are simply not taken and support handles the case.
The same order is visible in your account: the delivery can be copied or downloaded as a file again, position by position if needed. The shop sends no email notifications — it has no mailbox.
Receiving a batch ordered by a script
Automated purchasing does not cancel hand-over, it speeds it up. The replacement window is thirty minutes from delivery, and for a script that means the comparison has to happen in the same run rather than the next morning.
- Compare the number of delivered lines with the quantity ordered.
- Check the field set: the format of a batch is written in the position title and decides what should arrive at all. The format converter on the site splits the line into fields.
- Do not change the password, the mail or the linked data until the check is over — after any such change the guarantee no longer applies.
- If you did not make it in time or the contents do not match, write to the support bot with the order number and the position sku.
This differs from a manual hand-over in exactly one way: the comparison is done by code, while the decision to replace is still made by a human in the support bot. So it pays to have the purchasing script store the order number and the sku next to the comparison result — that pair is the first thing you will be asked for.
Service endpoints: availability and key usage
Two endpoints are worth keeping in monitoring from day one. The first answers whether the address is alive and needs nothing but the request — it tells «the shop is down» apart from «the key was revoked». The second shows how many requests the key has spent today and what its per-minute ceiling is.
The limit values are printed on the cards above and are counted independently: one limit per endpoint, another per key. The usage endpoint exists so that you see the ceiling approaching in advance: being refused on a limit at purchase time costs more than a pause between requests.
Questions and answers
Useful pages