v1.3 API Update: Bulk Shortening Endpoint

Today we are releasing v1.3 of the Plung public API, focusing on our new Productivity suite. This update introduces a dedicated POST /v2/shorten/batch endpoint for generating multiple shortened links programmatically in a single request.

This capability is available on the authenticated public API, so batch requests now use the same Bearer-token authentication as the rest of /v2.

Building at Scale

When building automated workflows, efficiency matters. Developers frequently need to process lists of links for email newsletters, SMS campaigns, or social media bots.

Previously, this required sending individual HTTP requests for every single link. At scale, this repetitive network overhead slows down processing pipelines and increases latency.

Now, Plung handles this natively. By using the new batch endpoint, you can submit up to 50 URLs—along with custom aliases, expirations, and passwords—in one array. This massively reduces network round trips and speeds up your internal systems.

Practical Example: Newsletter Links

Imagine an automated newsletter publisher that needs to track click metrics for multiple daily articles. Instead of looping through fetch calls sequentially, you can process the entire list at once.

const response = await fetch("https://api.plung.co/v2/shorten/batch", {
  method: "POST",
  headers: {
    "Content-Type": "application/json",
    "Authorization": "Bearer your_api_key_here"
  },
  body: JSON.stringify({
    urls: [
      { url: "https://example.com/article-1" },
      { url: "https://example.com/article-2", alias: "daily-tech-2" },
      { url: "https://example.com/sponsor", expiresIn: 86400 }
    ]
  })
});

const { results } = await response.json();
console.log(results);

Graceful Partial Failures

A core design decision in v1.3 is our approach to partial failures. In a batch of 50 URLs, it's common for one or two to fail validation, perhaps because an alias is already taken or a source URL is malformed.

Rather than rejecting the entire batch with a 400 Bad Request and forcing developers to retry the successful items, the batch endpoint gracefully returns a 200 OK response. Every item in the returned results array includes a success boolean.

If an item fails, its individual result object simply contains an error string explaining why (e.g., "Alias is already taken"), while all valid URLs in the same array are successfully shortened. This allows your scripts to process the successes while cleanly logging only the specific failures.

Full details on schema requirements, rate limits, and partial failure structures can be found in our Developer Documentation.

The Plung API remains free and open. We look forward to seeing the high-volume workflows you build with this feature.