API: Give a Quarantine ID or QID, how to delete via API?

CaptainPalapa

[Subject should read: “Given a….”.]
I know the Quarantine Notification emails contain a long large link to either delete a quarantined message or move it to the inbox. But I really dislike the inability to perform actions on multiple emails at once. I’ve built out my own UI for managing both Junk and Quarantine email, just for my staff.

The problem is that I cannot seem to locate the API call that would allow me to inbox those messages. The API has a /api/v1/delete/qitem but that’s just delete, not “move to inbox”.

As a poor second choice, if I could get the long value used in the links that come in the notification emails, like [https://mail.example.com/qhandler/release/bc944b5a7f121364747bf774d041d264be144a0a3f12260b59a1b2cc0a864e7d], then I could at least loop / ajax the API hits. I’d rather send a list to the API in one fell swoop, if possible, per email address.

CaptainPalapa

Obviously a holiday weekend, so I decided to dig on my own. While the /api URL returns an awesome, beautiful Swagger doc setup, it is in an incomplete set of API documentation. This is what I discovered from using the built-in web administration interface (in the case of the API, be sure to use the X-API-Key header as with other API calls)
POST to https://mail.example.com/api/v1/edit/qitem
JSON body of { attr: {"action":"release"}, items: ["69","68"]}

Here’s the response, I received after calling this:
{"type":"success","msg":"Task completed"}

Unfortunately, my next refresh / retrieve of the Quarantine items still showed those entries present. The request I tracked via the admin interface also had a csrf_token value, which of course I didn’t have available with an API call, so I didn’t send that key. I was really hoping that, as I documented this “successful” looking response for others in this forum reply that it was going to work. It says “success”, after all. But, again, re-retrieving the quarantine list shows the same items still there.

Any suggestions?

Testing in Postman. Seems that it doesn’t matter what I send, I’ve done a “success” ful job.

And I eventually solved it. (Sorry for the forum spam, I guess, but I tend to need to talk/type things out.)

My next test was to ensure that all the items in the “items” array were strings, not numbers. Going back to test, that wasn’t it. The problem was proper casing. Which I didn’t notice initially. I’m coming from Lucee / Coldfusion, which, if you don’t quote object/structure keys, like {action: "release"} vs. {"action": "release"} then case isn’t preserved. I was sending “ACTION”, not “action”. I guess the mailcow API decides… okay, I did all the “action(s)” that you sent. Which were none. I would prefer, obviously, an error be thrown indicating something like “no eligible actions received”.

When I got it right, this was the response for releasing two messages:
[{"type":"success","log":["quarantine","edit",{"id":[217,219],"action":"release"}],"msg":["item_released",217]},{"type":"success","log":["quarantine","edit",{"id":[217,219],"action":"release"}],"msg":["learned_ham",217]},{"type":"success","log":["quarantine","edit",{"id":[217,219],"action":"release"}],"msg":["item_released",219]},{"type":"success","log":["quarantine","edit",{"id":[217,219],"action":"release"}],"msg":["learned_ham",219]}]

Unfortunately, I taught some “ham” I shouldn’t have. Oof.