The list of assertions appears to be missing “preseed”, https://github.com/snapcore/snapd/blob/master/asserts/asserts.go#L140
This is a lot of content for a single page, I would be tempted to give each API endpoint its own page. I would also explain that if one installs the “http” snap, that snap understands the “snapd:” schema so you can run simple commands like:
$ http snapd:///v2/apps
which is really cool. Otherwise, you can use the standard “curl” invocation.
If you peruse the code here, https://github.com/snapcore/snapd/tree/master/daemon, there appear to be a number of API endpoints that are not listed here, including buy, cohorts, debug, download, quotas among others.
Oh, and create-user as well.
And system-recovery-keys.
we do not make compatibility promises about debug, so if documented it should be documented separately
download is still wip
cohorts and system-recovery-keys can/should be documented
everything else you mentioned is obsolete/deprecated, might get removed
I just noticed this commit, https://github.com/snapcore/snapd/commit/f271e0815e5dc9f2cb6f1a19b94cc2cc93c08ea7, which seems to merge a commit entitled “daemon: /v2/system-recovery-keys remove API”. But that commit doesn’t seem to remove the API, just extend it. Can someone clarify this so I can make sure I document this correctly?
I’d read it as “it removes the keys” … not the API…
yes, that’s adding remove support
Ah, thanks. I need to read more carefully. Just trying to update this page.
There still seem to be some endpoints not documented here – at a glance, “accessories” is not mentioned. There are probably others, unless some endpoints are deliberately not included here.
Thanks - I’ve got quotas on my immediate todo, but I’ll look again into what else we should have.
Edit (28th June 2023): quota group documentation has now been added.
“accessories” is not documented because it is limited to snaps with snap-themes-control allowed, which is a bit of a special use case
1 Like
Hello!
In my tests, there is another status: Wait. This appears on classic or hybrid images when you try to refresh a snap that requires a reboot (for instance, the kernel snap, such as pc-kernel). The snap change command will show the status as Wait with a message saying snapd is waiting for the device to be manually rebooted:
$ sudo snap refresh pc-kernel --channel=22/beta
(...)
$ snap change 379
Status Spawn Ready Summary
Done today at 04:25 UTC today at 04:25 UTC Ensure prerequisites for "pc-kernel" are available
Done today at 04:25 UTC today at 04:25 UTC Prepare snap "" (1731)
Done today at 04:25 UTC today at 04:25 UTC Run pre-refresh hook of "pc-kernel" snap if present
Done today at 04:25 UTC today at 04:25 UTC Stop snap "pc-kernel" services
Done today at 04:25 UTC today at 04:25 UTC Remove aliases for snap "pc-kernel"
Done today at 04:25 UTC today at 04:25 UTC Make current revision for snap "pc-kernel" unavailable
Done today at 04:25 UTC today at 04:25 UTC Update assets from kernel "pc-kernel" (1731)
Done today at 04:25 UTC today at 04:25 UTC Copy snap "pc-kernel" data
Done today at 04:25 UTC today at 04:25 UTC Setup snap "pc-kernel" (1731) security profiles
Wait today at 04:25 UTC - Make snap "pc-kernel" (1731) available to the system
Do today at 04:25 UTC - Automatically connect eligible plugs and slots of snap "pc-kernel"
Do today at 04:25 UTC - Set automatic aliases for snap "pc-kernel"
Do today at 04:25 UTC - Setup snap "pc-kernel" aliases
Do today at 04:25 UTC - Run post-refresh hook of "pc-kernel" snap if present
Do today at 04:25 UTC - Start snap "pc-kernel" (1731) services
Do today at 04:25 UTC - Clean up "pc-kernel" (1731) install
Do today at 04:25 UTC - Run configure hook of "pc-kernel" snap if present
Do today at 04:25 UTC - Run health check of "pc-kernel" snap
Wait today at 04:25 UTC - Monitoring snap "pc-kernel" to determine whether extra refresh steps are required
......................................................................
Update assets from kernel "pc-kernel" (1731)
2024-04-08T04:25:43Z INFO No gadget assets update needed
......................................................................
Make snap "pc-kernel" (1731) available to the system
2024-04-08T04:25:55Z INFO Task set to wait until a system restart allows to continue
......................................................................
Monitoring snap "pc-kernel" to determine whether extra refresh steps are required
2024-04-08T04:25:55Z INFO Task set to wait until a system restart allows to continue
Is this an omission in the documentation?
Thanks for asking this, and for your detailed summary. I’ll ask the team today and get back to you - hopefully updating the doc.
Update (11th April 2024): I spoke to the team about this, and Wait as indeed an omission as some of this work was done later. It basically means the task was successful but dependent on the occurrence of an event outside of its direct control (such as a reboot after a kernel snap update on classic systems). I’ve added this now.
1 Like
Question: there is the new snap-refresh-observe interface, which gives access to a reduced API from inside a snap. Will the available methods be specified in some form here? Also, I sent a patch to add access to /v2/snaps/{name} method (api-snaps: add refresh-observe access to /v2/snaps/{name} by sergio-costas · Pull Request #13931 · snapcore/snapd · GitHub), and it has the “needs documentation” tag. I presume it is here where I have to comment it…
Question: there is the new snap-refresh-observe interface
Sorry for the long delay getting back to you on this. I’ll ask the team and update the REST API doc accordingly. Thanks for letting us know.
Can someone please update the section on recovery systems to mention that remove is a valid action (per Create a recovery system from the REST API | Ubuntu)?
Hi 
Can the purpose of POST /v2/system-recovery-keys with {"action": "remove"} be clarified a bit ?
Is it to remove the potential of using a recovery key in the future, or so somehow reset the key so a new one is set up [ which the doc linked seems to suggest ] ?
Also, when tried using that API endpoint [ part of me trying to discover move about the intent of it ], I just got a HTTP 400.
Posting:
URL: http://snapd/v2/system-recovery-keys
Params: {'action': 'remove'}
Returns:
{'result': {'message': 'cannot decode recovery keys action data from request '
'body: EOF'},
'status': 'Bad Request',
'status-code': 400,
'type': 'error'}
Are the docs not quite right, or am I doing something wrong ?
Thanks!
Cheers, Just
Hi @pedronis
As you specifically mentioned removing recovery keys earlier in this thread, can you help answer my question above ?
Thanks!
cheers, Just
That looks like the json is not formatted right. Are you sure you have passed the json correctly? Maybe you passed it as query instead of data?
This is what I get on a VM:
valentin.david@ubuntu:~$ sudo snap recovery --show-keys
recovery: 30233-64610-53674-13056-04434-14422-07941-46081
valentin.david@ubuntu:~$ echo '{"action": "remove"}' | sudo snap debug api --request=POST /v2/system-recovery-keys
{
"result": null,
"status": "OK",
"status-code": 200,
"type": "sync"
}
valentin.david@ubuntu:~$
Hi @valentind - thanks for your response 
First of all, thanks for the example using snap debug api, I wasn’t aware of that, and it’s super useful. I’ve typically been copying over some python code using a requests HTTP adaptor to talk to the snapd socket, which works but isn’t quite as handy/immediate!
Even further, the python code was the issue. Unfortunately I didn’t check it properly at the time, and there was a small typo. The requests works fine now , so thank you
Cheers, Just