← Back to Skills
SEO

LinkBunny

Hwee-Boon Yar By Hwee-Boon Yar 👁 8 views ▲ 0 votes

LinkBunny lets your coding agent handle nofollow backlink exchanges with other participating sites. Install the Skill, create an API token, and register each site with a target URL and the part of the site where links may go. LinkBunny reviews each new site before it can match. On each check-in, the agent gets one link request, looks for a relevant spot on your site for a contextual nofollow link, and asks you before anything is published. Incoming links depend on matches in the network and are not guaranteed. A paid LinkBunny subscription is required to use the API. Also on ClawHub as linkbunny. Setup and API docs are at https://getlinkbunny.com/docs/agents

---
name: linkbunny
description: Lets a coding agent handle nofollow backlink exchanges with other LinkBunny sites, with the site owner approving every placement. Use when user says "build backlinks" or "linkbunny"
version: 1.0.1
metadata:
  openclaw:
    homepage: https://getlinkbunny.com/docs/agents
---

# LinkBunny agent skill

## At a glance

LinkBunny gives your coding agent one link request at a time from another participating site. The agent looks for a relevant spot on your site for a contextual nofollow link, shows you the exact change, and publishes only after you approve it. LinkBunny never edits your site.

You need a LinkBunny account, a paid subscription and an API token. Create all three at `https://getlinkbunny.com`. The API has no signup, billing or token endpoints.

Ask the owner before each step below. An earlier yes does not cover a later step.

1. Register a site with `POST /profiles`. Save the returned `profileID` privately. LinkBunny reviews each new site once before it can match.
2. Check in with `POST /profiles/{profileID}/check-in`. The response has one assignment or none. Do not poll or schedule check-ins.
3. Look for an existing page inside the returned `inventoryPrefix` where the link fits naturally.
4. Show the owner the proposed link and wait for a decision (see "How the owner reviews a proposed link").
5. After approval, publish through the owner's usual workflow and check the live page.
6. Record the outcome with `PUT /assignments/{assignmentID}/report` after publishing, or `PUT /assignments/{assignmentID}/reject` when nothing fits.

### API token handling

- Keep the token in the owner's secret store or an untracked env file, and load it as `LINKBUNNY_API_TOKEN`.
- Send it only as `Authorization: Bearer <token>` to `https://api.getlinkbunny.com/v1`. Never send it to any other host.
- Never print, echo, log, paste into chat, screenshot or commit the token.
- If the token was exposed, tell the owner to revoke it and create a new one on the account page.
- LinkBunny never needs repository, hosting, deployment or provider credentials. Don't send them.

### How the owner reviews a proposed link

Before changing any file or page, show the owner:

- the target site the link points to
- the existing source page where it would go
- the sentence with the link in place, as a diff when the site lives in a repository
- the anchor text and `rel="nofollow"` on the link

The owner approves, asks for a different spot or wording, or declines. Without approval, change nothing. After publishing, show the owner the live page and confirm before reporting it to LinkBunny. If nothing fits, tell the owner why and reject the assignment after they agree.

### Request fields

Every request goes to `https://api.getlinkbunny.com/v1` with the `Authorization: Bearer <token>` header. Requests with a body send it as JSON with `Content-Type: application/json`.

- Create a profile: `POST /profiles` with `targetURL`, `requestedAnchor` (1 to 200 characters), `category` (one of the values listed under "A — Create a profile") and `inventoryPrefix`. The response includes `profileID`.
- Update a profile: `PATCH /profiles/{profileID}` with the same four fields.
- Check in: `POST /profiles/{profileID}/check-in` with no body. The response has an `assignment` field. When it is not null, it holds `assignmentID`, `targetURL`, `targetDomainRating`, `requestedAnchor`, `category`, `inventoryPrefix` and `expiresAt`.
- Report a placement: `PUT /assignments/{assignmentID}/report` with `pageURL` (the live source page), `actualAnchor` (the published anchor text, 1 to 200 characters) and `linkAttribute` set to `nofollow`.
- Reject an assignment: `PUT /assignments/{assignmentID}/reject` with `reason` set to one of `no_relevant_context`, `target_unavailable`, `policy_conflict` or `other`.
- Errors return an `error` object with `code` and `message` fields. Status codes and retries are covered under "Retry and status rules" below.

The full rules follow. Where this summary and the rules below differ, the rules below win. The latest copy is always at `https://getlinkbunny.com/skill.md`.

LinkBunny gives participating sites link requests and records self-reported results; it does not edit
any site. A coding agent finds a genuine place for a contextual nofollow link. The owner approves
publishing through the site's normal workflow, or rejects the request.

## Prerequisites and sequence

1. A LinkBunny account is required. The human may create an account or log in at
   `https://getlinkbunny.com`; an agent may do so only with explicitly authorized browser control.
2. An eligible paid subscription is required before entitled operations. The human must authorize
   starting, changing, or cancelling billing; an authorized browser-capable agent may operate the
   website UI for that approved action.
3. With an active subscription, create an API token in the account UI. The human must authorize
   each creation, rotation, or revocation; an authorized browser-capable agent may perform it. Copy
   the token once into an owner-approved secret store and keep it secret.
4. Use that token for the public API workflow below. The public API does not provide signup, login,
   token-management, billing, subscription-status, or other account-management endpoints.

Human authorization and browser capability are separate: only the human can authorize account,
billing, credential, site, assignment, publication, report, or rejection actions. An agent may
carry out an authorized website action only when it has explicitly authorized browser control, and
may carry out an authorized API or site action only within the approval given.

## Activation and approval gates

Use LinkBunny only when the owner explicitly asks you to onboard, register an owned site, check that
site for LinkBunny work, or report/reject an assignment. Do not autonomously sign up, log in,
subscribe, manage credentials, register sites, check in, place links, report, reject, or publish.

Obtain action-time owner authorization before signup or login/account operations, token creation or
rotation, subscription or billing changes, each site registration, assignment check-in/reservation,
publication, report, or rejection. A prior setup approval is not blanket approval for later actions.
The owner may explicitly authorize a bounded set of replacement check-ins for the current task; that
authorization covers only the stated bound. General agent autonomy does not authorize a check-in.
An assignment authorizes consideration only within the returned inventory boundary; it never
authorizes publication.

Explain assignment decisions concisely and naturally in the conversation's language (English when
the conversation is in English). Identify the target by its human-readable site or domain and the
source by an ordinary page or site-area description. Do not expose tokens, private data,
profile/assignment IDs, requested anchors, full URLs, API endpoints, or reason codes when those
plain-language descriptions are enough.

## Safety contract

- API base: `https://api.getlinkbunny.com/v1`.
- Put the account token in `Authorization: Bearer <token>`.
- Keep tokens in an owner-approved secret store. Never print, echo, log, paste into chat, include in screenshots, write to source/config tracked by Git, or commit them.
- Register only sites the owner is authorized to manage.
- Never send repository, hosting, deployment, or provider credentials to LinkBunny.
- Stay inside the exact returned inventory origin and path prefix. `/articles-old/` is not inside `/articles/`.
- Inspect the owned corpus and place a link only where it is genuinely relevant. Use truthful surrounding text and a natural anchor; the requested anchor is guidance.
- Every assigned link must include `rel="nofollow"`. Security attributes such as `noopener` may also be present.
- Reject forced, unrelated, hidden, template-wide, or thin placements. Do not create filler content merely to place a link.
- V1 is self-reported. Do not describe a report as independent verification or promise rankings, traffic, timing, permanence, DR equivalence, or search-policy safety.

## Operations

### A — Create a profile

After specific authorization, `POST /profiles` with `targetURL`, `requestedAnchor`, one documented
`category`, and `inventoryPrefix`. Both URLs must be public HTTPS URLs without credentials or
fragments, on the same registrable domain. This operation requires an active subscription. A
successful Domain Rating lookup returns `201` with status `pending_review`. LinkBunny reviews each
new profile once before it can match as a source or target. Tell the owner review is pending and
suggest asking the agent to check again after the advisory interval or once approval is confirmed.
Immediately record and retain the response's canonical `profileID` in the owner's approved private
configuration (for example, `LINKBUNNY_PROFILE_ID` in an untracked env file). Later profile updates
and check-ins require that exact ID; do not invent a label, alias, or replacement identifier. If it
was not retained, the signed-in owner can recover it from the private Account page. There is no
public profile-list endpoint.
Marketplace review is not an execution blocker; do not poll automatically. A transient rating failure returns
status `pending`; after cooldown, the next authorized check-in retries once and then reports the
review-pending state. Approval is profile-level: approved profiles use immediate assignment without
per-assignment LinkBunny approval.

If profile creation fails with `Active profile entitlement reached`, tell the owner in plain English
that they may email `[email protected]` to request a higher active-profile allowance. Do not
imply that an increase is guaranteed, automatic, free, or available through the public API.

`category` describes the registered site's domain. Choose the closest truthful value; use `other`
only when no more specific category fits:

- `developer_tools` — Software development, APIs, infrastructure, or technical tools
- `design_media` — Design, creative work, visual media, audio, or video
- `marketing_sales` — Marketing, advertising, sales, or customer acquisition
- `social_creator` — Social platforms, communities, newsletters, or creator businesses
- `business_operations` — Finance, legal, HR, productivity, or business operations
- `ecommerce` — Online stores, retail, products, or shopping services
- `other` — Sites that do not truthfully fit a more specific category

After specific authorization, `PATCH /profiles/:profileID` accepts the same fields. Changing the
target or inventory URL materially resets the profile to Domain Rating lookup and one-time review;
it cannot match during re-review. Anchor- or category-only edits preserve an existing approval.

### B — Check in

After specific authorization, `POST /profiles/:profileID/check-in`. This operation requires an
active subscription. The response contains the same existing pending assignment, one newly
reserved assignment, or `assignment` set to `null`. A profile awaiting review instead returns
`assignment` set to `null`, `status` set to `profile_pending_review`, a `message` saying the site is
awaiting marketplace review, and `retryAfterSeconds` set to `3600`; the one-hour interval is advisory, and every check-in still requires specific owner authorization.
Do not poll automatically. A rejected
profile returns `profile_rejected` and must not be retried as if no assignment were available. Store
no marketplace database. Retain the returned assignment ID privately until you report or reject it;
do not expose or discard it. Do not infer that plain null is an
error. When a check-in returns plain null, tell the owner in plain English: "No assignment is
available right now. You may ask me to check again later. A later check-in is operationally safe and
idempotent when a pending assignment exists: it returns that same assignment, but if none exists it
may reserve a new assignment. Because of that, every later check-in needs your fresh, specific
authorization unless it remains inside an explicit bounded check-in authorization for this task. I
won’t poll, schedule, or retry automatically. If you just rejected an assignment, there may be no
eligible replacement until marketplace candidates change."

An assignment includes `targetDomainRating`, the target domain's Domain Rating when the assignment
was reserved. It can be `null` only for an assignment created before LinkBunny began snapshotting
this value. After receiving an assignment, tell the owner which target site or domain you will look
for a suitable place to mention and which eligible area of the source site you will inspect. This
describes the next investigation only; obtain separate owner authorization before publishing
anything.

LinkBunny matches candidates within a bounded Domain Rating gap, including the limit. The marketplace
operator may periodically adjust this range as marketplace supply changes. Being within range does
not guarantee an assignment.

Distinct profiles on distinct registrable domains may match even when the same account owns them;
balances remain isolated per profile. A profile is never eligible to target itself. LinkBunny does not assign the reverse of a
pair while the first direction is pending or after it is reported. Expiry or rejection releases
reverse-direction eligibility.

A target is excluded after three successfully settled inbound backlinks during the current UTC
calendar day. Pending, rejected, and expired/unreported assignments do not consume this daily
capacity; eligibility resets at the next UTC midnight.

Send the check-in request with no body and no `Content-Type` header. Clients that always send JSON
may send an empty JSON object.

### C — Report completion

Before requesting separate publication authorization, name the target site or domain, the existing
source page or eligible site area, and the genuine editorial context and placement you propose.
Follow the owner's normal publication workflow only after authorization. After it succeeds, inspect
the rendered/live result. Confirm the exact `pageURL` is within `inventoryPrefix`, the actual anchor
matches what was published, and the link contains `nofollow`. Tell the owner plainly what was linked
and where, then obtain report-completion authorization without unnecessary API jargon. After
authorization, `PUT /assignments/:assignmentID/report` with `pageURL`, `actualAnchor`, and
`linkAttribute` set to `nofollow`; once confirmed, say that LinkBunny recorded the placement.

### D — Reject

If no suitable context exists or publication should not proceed, make no site change. After specific
rejection authorization, `PUT /assignments/:assignmentID/reject` with `reason` set to one of
`no_relevant_context`, `target_unavailable`, `policy_conflict`, or `other`.
Before requesting that authorization, name the target site or domain and give the specific
plain-language reason no suitable context exists or publication should not proceed. A rejected
outcome uses the reject endpoint, never the report endpoint.

After LinkBunny durably confirms the rejection, clearly say which target was rejected and why, then
ask whether the owner wants one check-in now for another assignment. If the owner already explicitly
authorized autonomous or batch replacement check-ins for this task, perform that one next check-in
under the existing authorization instead of asking again. Never infer this authorization from
general agent autonomy, and never schedule, poll, create an infinite rejection/check-in loop, or
continue beyond the explicit bound. The rejected assignment is no longer pending, so the
same-pending-assignment behavior does not apply: the next check-in may return no assignment or
reserve a new assignment.

Rejection permanently excludes only that exact directional pair (source profile → target profile)
from future matching; the reverse direction remains eligible. It releases the target reservation
immediately, so another source may receive its own assignment with a fresh seven-day deadline.

If the owner later publishes the originally requested backlink, obtain report-completion
authorization and use the original rejected assignment ID no later than its unchanged original
`expiresAt`. The exact timestamp is included. Rejection does not extend or restart the window, and a rejected
assignment has no 30-day late-report window. A successful reconsidered report returns `reported`.

## Retry and status rules

B and identical successful C or D requests are idempotent. Retry the same operation and assignment after a
transport interruption; a retry does not require new authorization when it is strictly the same
previously authorized action. Never change report/reject details merely to make a retry pass. A
conflicting report or rejection retry returns `409 idempotency_conflict`; another terminal conflict
may return `409 terminal_conflict`. Expected errors return an `error` object with `code` and `message` fields, with
400 invalid request, 401 credential failure, 403 entitlement failure, 404 unavailable owned
resource, or 409 terminal conflict.

When create-profile or check-in returns a subscription-required `403`, tell the owner that a paid
LinkBunny subscription is required and must be completed through the account website at
`https://getlinkbunny.com/account`. Do not imply that signup, billing, token creation, or account
status is available through the public API. Report and reject remain available for already-issued
assignments so they can be settled after entitlement ends.

Pending assignments expire at their seven-day deadline. Expiration releases the reservation but
does not permanently exclude the directional pair. Report completion for the exact original
pending assignment remains available for 30 days after expiry as `reported_late`; do not treat that
window as permission to publish without current owner authorization. Rejected assignments instead
close at their original seven-day deadline and return `409 terminal_conflict` afterward.

Reverse assignment after expiry or rejection does not revoke these late or reconsidered reporting
rights. A valid report may therefore settle both directions; existing reciprocal assignments and
settlements also remain valid.

Because a rejected assignment releases its target immediately, its reconsidered report and reports
from newer assignments may all settle backlinks to that same target. The target profile balance may
temporarily fall below the ordinary target-selection allowance, including -2 or lower. The target
remains eligible as a source and recovers one balance step for every outbound placement it completes
until its profile-scoped balance moves back toward zero.
backlinks seo nofollow link-exchange coding-agents

Comments

Sign in to leave a comment

Loading comments...