Remove Labels from Bookmarks
Remove one or more labels from user bookmarks.
POST /v1/labels/remove detaches a label from one or many saved posts. It mirrors /v1/labels/add: identify the label by label_id or label_name, pass post_ids, and the removal is applied across the whole set in one request.
The response is more informative than the add path because removal has two distinct non-error outcomes. meta carries removed, requested and removed_post_ids, so you can tell 'removed from 3 of 5' apart from 'none of those posts carried that label' without diffing state yourself.
Example request
Authenticate with a bearer token in the Authorization header. Create a key on the API page in your LinkedMash settings and export it as LINKEDMASH_API_KEY before running this.
curl -X POST "https://api.linkedmash.com/v1/labels/remove" \
-H "Authorization: Bearer $LINKEDMASH_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"post_ids": [
"7336731872414035968"
],
"label_name": "Hooks"
}'Header parameters
Your secret API key. Should be provided as a Bearer token.
Body parameters
IDs of the posts to remove labels from.
ID of the label to remove.
Name of the label to remove.
Response
{
"status": true,
"data": {
"success": true
},
"message": "Labels removed from bookmarks"
}Response fields
Every response is wrapped in the same envelope: a status flag and a data payload, with meta present where there is pagination or a plan limit to report.
true on success. Every LinkedMash API response carries this envelope flag alongside data, so a client can branch on it without re-reading the HTTP status.
true when the request was processed. It is true even when nothing needed removing, so read meta.removed to tell the two apart.
Human-readable result. A no-op reads "None of those bookmarks carried that label, so nothing was removed."
How many posts actually lost the label.
How many post ids you sent. removed < requested means some of them did not carry the label.
The specific post ids that changed, so you can reconcile without a second read.
Retagging without losing track
Moving posts between labels is a remove plus an add, and the ordering matters less than reading the result.
Read the current tags
GET /v1/bookmarks returns a tags array per post. Diff it against the labels you want rather than removing blindly, so you know what you are about to change.
Remove, then add
Send the remove first. If the add fails you are left with untagged posts, which is recoverable; the other order can leave a post carrying both labels.
Reconcile on meta.removed_post_ids
The response names exactly which posts changed. Use it to update your own store instead of re-reading the library to find out what happened.
Distinguish a no-op from a failure
meta.removed of 0 with a 200 means none of those posts carried the label — that is a successful no-op, not an error. A genuinely bad label name returns 404 instead.
Behaviour and limits
Paid-only
As with add, a free key returns 402 with code SUBSCRIPTION_REQUIRED before any write.
An unknown label_name is a 404, not a silent success
If the name cannot be resolved to a label on the account the response is 404. This is the one place the two label endpoints differ in shape: add would have created that label, remove refuses to pretend it removed something.
A no-op is reported as a no-op
When none of the given posts carried the label the call still returns 200, but with meta.removed = 0 and the message "None of those bookmarks carried that label, so nothing was removed." Check meta.removed rather than the status code when the difference matters.
Removal fires a webhook
Each post that actually lost the label emits a label.removed event with post_id, label_id and label_name. Posts that did not carry the label emit nothing.
Errors
Failures carry the same envelope as a success, with the reason in message and a stable machine-readable code where the status alone is ambiguous — several distinct conditions share a 402.