Add Labels to Bookmarks
Add one or more labels to user bookmarks.
POST /v1/labels/add attaches a label to one or many saved posts in a single call. Identify the label either by label_id (from GET /v1/labels) or by label_name, and pass post_ids as an array — or a single id, which is accepted for convenience and treated as an array of one.
This is the bulk primitive behind every classification workflow: fetch a filtered page from /v1/bookmarks, decide a label, and write it back in one request rather than one call per post.
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/add" \
-H "Authorization: Bearer $LINKEDMASH_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"post_ids": [
"7336731872414035968",
"7331104558812631041"
],
"label_name": "Hooks"
}'Header parameters
Your secret API key. Should be provided as a Bearer token.
Body parameters
IDs of the posts to label.
ID of the label to add.
Name of the label to add (if creating a new one).
Response
{
"status": true,
"data": {
"success": true
},
"message": "Labels added to 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 label was applied across the given posts.
Human-readable confirmation naming the label and the number of posts affected.
Tagging a filtered set
This endpoint is the write half of every triage workflow. The read half is GET /v1/bookmarks.
Resolve the label first
Call GET /v1/labels and use the numeric label_id. Passing label_name works, but it creates the label when the name does not match — which is how accounts end up with three spellings of the same tag.
Select the posts
Page GET /v1/bookmarks with whatever filter defines the set. Collect post_id values rather than acting on each post as you read it.
Send one request per label
post_ids takes an array. A batch of 200 posts under one label is one call, not 200 — and it is one webhook fan-out rather than 200.
Retries are safe
Re-applying a label a post already carries does not duplicate it, so a request that timed out can simply be sent again.
Behaviour and limits
Paid-only
A key without an active subscription gets 402 with code SUBSCRIPTION_REQUIRED before anything is written. Reading labels stays available on free; writing them does not.
label_name creates the label if it does not exist
Passing a name that is not yet on the account creates it. That is convenient and it is also how duplicate near-identical labels appear, so prefer label_id from GET /v1/labels when you are automating.
Labelling fires a webhook
A successful add emits a label.added event to every webhook registered on the account, one item per post id, carrying post_id, label_id and label_name. The same event fires whether the label came from the app, the REST API or an MCP tool.
The write is idempotent in effect
Re-sending the same post_ids and label does not stack duplicates on a post, so a retry after a network error is safe.
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.