Link Shortener API Comparison: What Developers Get in 2026

Every link shortener sells the same demo: paste a long URL, receive a short one. The difference between them shows up three weeks later, when a queue worker is creating ten thousand links an hour, a webhook handler is silently dropping retries, and someone asks why last month's click data cannot be joined to the CRM. This comparison is about that stage rather than the demo.

What follows are the axes that decide whether an API survives contact with production, what the main vendors in the category actually offer along each one, and working examples against the LinkProfit API. Competitor behaviour here is described in prose rather than in fabricated code samples: request shapes change, and a copied snippet that no longer compiles is worse than a sentence that explains what the endpoint does.

Why the API Is the Product for Some Buyers

There are two kinds of shortener customer. One logs into a dashboard, creates links by hand, and reads charts. The other never opens the dashboard at all: links are created by their own software, on behalf of their own users, and the click data flows into their own warehouse. For the second kind, the dashboard is a debugging tool and the API is the entire product.

That distinction explains most of the disappointment in this category, and it is why embedding shortening into a SaaS product is a different purchase from buying a marketing tool. Vendors optimising for the first buyer treat the API as a checkbox on the pricing page: it exists, it is documented thinly, it is gated behind an upper tier, and it covers link creation but not domains, analytics or webhooks. If you are embedding shortening into a product, that gap is the difference between shipping and rewriting.

The Axes That Actually Matter

Authentication and key scope

The baseline is a bearer token. What separates implementations is what a leaked token can do. A single account-wide key that can delete every link is a liability, especially when your integration only needs to create them. Look for keys scoped to a workspace rather than an account, permissions attached to the key rather than to the user who created it, hashed storage with a one-time reveal at creation, and independent rotation so you can issue a key per service and revoke one without an outage.

Rate limits and behaviour at the ceiling

Two numbers matter and they are rarely both published: the sustained limit and what happens when you cross it. A well behaved API answers 429, tells you when to retry, and exposes the remaining budget on every response, so a client can self-throttle before it starts failing. An API that returns a generic 500 under load, or silently drops writes, forces you to build a conservative rate limiter around guesses.

Window shape matters as much as magnitude. A per-second ceiling and a per-minute sliding window with the same average throughput behave completely differently for bursty workloads, which is what most integrations produce: a campaign publishes, five thousand links are created in ninety seconds, and the queue is idle the rest of the day.

Bulk operations

Creating links one HTTP request at a time is fine at hundreds and painful at hundreds of thousands. A bulk endpoint that accepts a batch and returns per-item results, including partial failures with the index of the item that failed, turns an overnight job into a few minutes. The detail to check is failure semantics: whether a single invalid URL rejects the entire batch, and whether retrying a partially applied batch creates duplicates.

Analytics through the API

Almost every vendor shows click charts in its dashboard. Far fewer let you pull the same numbers programmatically at the granularity you need, and this is where per-plan limits hide. Ask for three things: aggregate summaries, time series with selectable granularity, and breakdowns by dimension such as country, city, device, browser, referrer and campaign parameters. Then ask about retention, export size caps, and whether events counted against your plan are the same events the API will return. The measurement questions underneath, bot filtering and unique visitor counting in particular, are covered in our guide to tracking link clicks.

Rebrandly is the clearest example of why this matters. Its redirects are unlimited, but the analytics themselves are metered as engagement data at 100, 10,000, 25,000 and 150,000 events per month across its tiers, as of August 2026. A link that keeps redirecting while it stops reporting is a specific failure mode you should price in before choosing.

Webhooks and delivery guarantees

Polling for state changes is how integrations become slow and expensive. Webhooks replace it, and their quality comes down to four properties: which events fire, whether payloads are signed, what the retry schedule looks like, and what happens after the retries are exhausted. Signature verification should be over the raw body with a timestamp to prevent replay. Retries should be spread over hours rather than minutes, so a deploy window does not cost you events. And the vendor should tell you when an endpoint has been marked as failing rather than discarding events quietly.

SDKs, specification and documentation

An official SDK saves a day of work; a machine-readable OpenAPI specification saves that day in whatever language the SDK does not cover, and keeps saving it as the API evolves. Short.io ships four SDKs, the widest official coverage in the category as of August 2026. A published specification is the more durable asset, since it generates clients, mocks and contract tests.

Errors, pagination and versioning

Three unglamorous properties that determine maintenance cost. Errors should be machine-readable, with a stable code separate from the human message, so your retry logic branches on the code rather than on string matching. Pagination should be cursor-based; offset pagination over a table that receives writes will skip and duplicate rows. And the version should be explicit in the path, frozen once published, with breaking changes shipped under a successor.

What the Vendors Offer

| Vendor | API availability | Published rate limit | Official SDKs | Notable constraint | | --- | --- | --- | --- | --- | | Short.io | All plans including free | 50 requests per second, more sold in blocks | Four | No white-label dashboard, teams are Enterprise only | | Dub | Core product, open-source codebase | Not published as a headline number | Yes | Partner white-labeling sits on the 300 USD tier | | Rebrandly | Paid tiers, features gated by plan | Not published as a headline number | Yes | Analytics metered as engagement events | | Replug | Agency plan only, 99 USD per month | Not published | No | API cannot be evaluated on lower tiers | | Shlink, self-hosted | Full, open source | Yours to configure | Community | Single-tenant assumptions, no billing | | LinkProfit | Growth plan and above | 600 requests per minute per workspace key | Specification-generated clients | Shared API hostname in version 1 |

All plan and pricing details above are as of August 2026.

Short.io: the volume benchmark

Short.io is the price and throughput aggressor in the category. Its API is available on every plan, the published limit is 50 requests per second regardless of tier, and additional capacity is sold in blocks of 50 requests per second for 50 USD per month. It ships four SDKs and a real developer documentation site, and custom domains with automatic certificates are included from the free tier upward.

The constraints are elsewhere in the product rather than in the API: what it calls white label is branding on links, not a rebrandable dashboard, multi-team support is confined to Enterprise, and retargeting pixel support covers only two networks. If you need those things, see our Short.io alternative comparison.

Dub: the API-first reference

Dub is the design and developer-experience benchmark of the category, with an open-source core and a product built API-first rather than dashboard-first. If you want a model for what good looks like in this space, read their documentation before writing your own integration requirements.

Two clarifications worth making, because the naming causes confusion. Dub Partners is affiliate-program infrastructure offered to Dub's customers, not a way to resell Dub itself, and its white-labeling sits on the Advanced tier at 300 USD per month as of August 2026. Their own affiliate scheme pays 30 percent of a sale for one year, which is a referral arrangement rather than a reseller model.

Rebrandly and Replug: the API as an upsell

Both gate developer access behind higher tiers, in different ways. Replug's API is available only on its Agency plan at 99 USD per month, 79 USD billed annually as of August 2026, which means you cannot evaluate the integration cheaply. Rebrandly's gating is feature by feature rather than a single wall: deep links appear only on Growth, retargeting pixels only from Professional, and the engagement data ceilings described above apply to analytics regardless of tier.

Neither approach is unusual, and both are workable if you sit above the threshold. The point for an evaluation is budget honesty: the tier you need for the API is the tier you are actually buying, not the one on the comparison table you started from.

Self-hosted and open source

If your requirement is an internal shortener with no billing and one tenant, Shlink is the strongest option: MIT licensed, PHP, genuinely API-first, with a mature client ecosystem. Its assumptions show when you try to serve other people. Slugs are globally unique across the instance rather than scoped per domain, API key roles do not approach real tenant isolation, and QR generation was removed in version 5. Kutt supports rebranding through a customisation directory but has slowed considerably, with 16 commits across 2026 and no teams, webhooks or multi-tenancy. YOURLS is one admin and one domain by design.

LinkProfit

Our design targets the second kind of buyer described at the top. Keys are issued per workspace or per partner, carry explicit scopes, are shown once and stored as a SHA-256 hash. The default limit is 600 requests per minute for a workspace key and 1,200 for a partner key, enforced with a sliding window, with X-RateLimit-Limit, X-RateLimit-Remaining and X-RateLimit-Reset on every response and Retry-After on a 429. Bulk creation accepts up to 100 links per call. Analytics are first-class rather than dashboard-only: summary, time series, dimensional breakdowns and a streaming CSV export capped at 100,000 rows. Webhooks are signed and retried five times over roughly twelve hours. The specification is generated from the same schemas that validate requests, so the documentation cannot drift from the implementation.

API access starts on the Growth plan, which is also the tier that unlocks a custom dashboard domain; the full breakdown is on the pricing page. The honest limitation in version 1: the API is served from a shared hostname, so white-label partners document it to their clients as their own API without it living on their own domain. That is a roadmap item, not a hidden one.

Working Against the LinkProfit API

Creating a link

curl -X POST https://api.linkprofit.com/v1/links \
  -H "Authorization: Bearer lp_live_xxxxxxxxxxxxxxxx" \
  -H "Content-Type: application/json" \
  -d '{
    "url": "https://example.com/spring-collection",
    "slug": "spring",
    "domain_id": "dom_7Kq2f9",
    "expires_at": "2026-10-01T00:00:00Z"
  }'

Batching writes

The bulk endpoint takes up to 100 links per call and returns a result per item, so a partial failure identifies the offending entry instead of rejecting the batch.

const response = await fetch('https://api.linkprofit.com/v1/links/bulk', {
  method: 'POST',
  headers: {
    Authorization: `Bearer ${process.env.LINKPROFIT_API_KEY}`,
    'Content-Type': 'application/json',
  },
  body: JSON.stringify({
    links: batch.map((row) => ({ url: row.destination, slug: row.code, domain_id: domainId })),
  }),
});

if (response.status === 429) {
  const waitSeconds = Number(response.headers.get('retry-after') ?? '1');
  await new Promise((resolve) => setTimeout(resolve, waitSeconds * 1000));
}

Reading analytics back

Breakdowns take a dimension parameter, which keeps the surface small and predictable rather than adding an endpoint per chart.

curl -G https://api.linkprofit.com/v1/analytics/breakdown \
  -H "Authorization: Bearer lp_live_xxxxxxxxxxxxxxxx" \
  -d dimension=city \
  -d date_from=2026-07-01 \
  -d date_to=2026-07-31

Available dimensions cover country, city, device, browser, operating system, referrer and the three main campaign parameters, which is enough to reproduce the dashboard's numbers in your own reporting.

Verifying a webhook

Events carry X-LinkProfit-Signature in the form t=timestamp,v1=hex. The signed payload is the timestamp, a dot, and the raw request body, so verification must happen before any JSON parsing that might reserialise it.

import { createHmac, timingSafeEqual } from 'node:crypto';

export function isValidSignature(rawBody, header, secret) {
  const fields = new Map(header.split(',').map((pair) => pair.split('=')));
  const timestamp = Number(fields.get('t'));
  // Reject anything outside a five minute window to limit replay.
  if (!Number.isFinite(timestamp) || Math.abs(Date.now() / 1000 - timestamp) > 300) return false;

  const expected = createHmac('sha256', secret).update(`${timestamp}.${rawBody}`).digest('hex');
  const received = Buffer.from(fields.get('v1') ?? '', 'hex');
  const computed = Buffer.from(expected, 'hex');
  return received.length === computed.length && timingSafeEqual(received, computed);
}

Failed deliveries are retried after one minute, five minutes, thirty minutes, two hours and twelve hours. After the last attempt the endpoint is marked as failing and the account owner is emailed, so a broken handler surfaces as a notification rather than as missing data discovered a month later.

Evaluating an API in an Afternoon

1. Create a key on the cheapest plan that includes API access, and note whether that plan is one you would otherwise buy.
2. Create, read, update and delete one link, and check that the responses carry rate limit headers.
3. Deliberately exceed the limit and confirm you receive a 429 with a retry hint rather than a generic failure.
4. Send a bulk request containing one invalid URL and inspect how partial failure is reported.
5. Pull a breakdown by city for last month and compare the totals with the dashboard.
6. Register a webhook against a request-capture endpoint, trigger an event, verify the signature, then take the endpoint offline and watch the retry schedule.
7. Request the OpenAPI document and generate a client from it.
8. Read the versioning policy and the changelog for the last twelve months.

Steps three, four and six are the ones most evaluations skip, and they are the ones that predict how the integration behaves at two in the morning.

The category has a genuine reference implementation in Dub, a genuine volume option in Short.io, and a long tail of products where the API is an upsell rather than a design goal. Our own approach, scoped keys, published limits with honest headers, analytics and domains as first-class resources, and a specification generated from the validation schemas, is documented at API features, with quickstarts, pagination, error codes and webhook guides in the documentation.