The first thing to note is that there are two objects at play here: the first level, which is your access to the card (called a membership) and the card itself (common to all users with access to it), which is the sub-section keyed by card
.
ID questions
- The top level ID is the ID of your membership,
card.id
is the ID of the card. - They are indeed UUIDs – UUID v4.
- Yes.
- No, an error will occur telling you this card or membership already exists.
Request fields:
-
status
: at the root (membership) level, this is whether the card is kept (2
), unkept (1
), pending (0
), or junked (-1
). At the card level this is only used internally. -
perms
: your permission on the card. This is handled by the backend system, so when you create a card, anything you put here will be discarded and replaced with Author permissions.
Hope that makes everything a bit clearer.
But yes, the UX of the API is something we are actively working on, so always open to suggestions if you find anything too cumbersome. Luckily the requirement to do your own markdown parsing is going away as part of the transition to the new WYSIWYG editor.