New OpenAPI docs

Hello folks,

I experimented with Claude a bit and generated an OpenAPI documentation in the OpenAPI 3.0 Yaml format.

This docs is available in human-readable form as Checkvist Open API

Also, I’ve added a section regarding modification of the list item tags.

Hope it will be useful, tell me what you think.

Best,

2 Likes

:slight_smile: – I needed it a month ago and then did the same thing (openapi: 3.1.0), and in addition had Claude generate a feedback document for you, but never got around to sending it. If you’d be interested, just let me know. (Is there a private mail/message option here?)

Edited: It shows the value of what you did versus what could have been discovered before. Thanks.

Ok. I can now trash my version. Two things:

BugPOST /checklists/{id}/tasks/{task_id}/tags.json returns text/javascript, not JSON.
Called with .json (or .xml), the tag-update endpoint returns the web-UI JS response (maxkir.TaskData[<id>]["tags"] = {…}) instead of the documented JSON Task[] — the format suffix seems ignored here (every other endpoint honors it). The tag change itself applies fine; only the response format is wrong. Observed on checkvist.com, 2026-06-07.

Feature request — expose a list’s inbound “email to list” address via the API.
It’s only visible in the web UI today. Use case: regenerating the Remote API key invalidates every list’s email address, and there’s no API to read the new ones — so you have to click through each list by hand. A field on the checklist object (e.g. inbound_email) and/or a regenerate endpoint would let a client resync them automatically after a key rotation.

Thanks again for the API — and for publishing the OpenAPI spec!

1 Like

Aren’t the email-to-list addresses consistent, though? They always seem to be post+{key}+{checklist_id}@checkvist.com.

Hi @Ralf,

Thanks for the follow-up and the feedback! It is interesting that you needed this around the same time I played with it :slight_smile:

If you click on the userpic in Discourse, there is a “Message” button in the top right corner. I haven’t used it yet, but I presume it should work. Do you see it?

This shoud currently work only on beta, as I’ve modified this endpoint together with updating the OpenAPI docs. And it is released on beta only yet.

Thanks for the suggestion, quite reasonable. Will try to delegate this to an agent and see how it goes :slight_smile:

Thanks again!

Hi @Josh, the {key} above is derived from the OpenAPI remote key from the profile page. So if the OpenAPI remote key is re-generated, corresponding e-mail addresses for the feature should be re-obtained, too.

Best,
KIR

Hi folks,

On beta, we’ve added support for with_inbound_email=true parameter for API requests for lists, this parameter adds inbound_email field to the output.

Please check it out :slight_smile:

Kind regards,
KIR