Developers··4 min read

Create Short Links with cURL and the OpenMyLink API

The fastest useful API workflow is not just creating one short link. It is creating a repeatable request pattern your team can reuse across launches, channels, and reporting jobs.

If you want to create short links with cURL, the goal should not be to prove that one request works once.

The better goal is to build a request pattern your team can repeat safely across launches, channels, and automation jobs. That is what turns a quick API test into a real operations workflow.

Why cURL is still the best place to start

cURL keeps the API visible.

Before you wrap link creation inside a script, app, CRM sync, or spreadsheet automation, it helps to see the request clearly:

  • the endpoint
  • the authentication method
  • the JSON payload
  • the response structure
  • the fields your team actually needs to preserve

OpenMyLink's public developer API page and API recipes are useful here because they already document bearer authentication, OAuth 2.0, JSON requests and responses, and example requests for links, QR codes, analytics, files, and bio pages.

OpenMyLink's public API examples show the POST /api/url/add pattern. A simple working shape looks like this:

curl -X POST https://openmy.link/api/url/add \
  -H "Authorization: Bearer YOUR_API_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "url": "https://example.com/spring-sale-page",
    "custom": "spring-sale",
    "utm_source": "newsletter",
    "utm_medium": "email",
    "utm_campaign": "spring-2026"
  }'

In OpenMyLink's public documentation, a successful response follows the platform's standard JSON pattern with error: 0 and the relevant returned data.

That matters because a cURL workflow is easier to operationalize when the response shape is predictable enough to hand off into scripts and reporting jobs later.

1. Make sure your campaign fields are stable first

A short-link API is only as useful as the metadata discipline around it.

If every request uses different campaign names, source labels, or alias patterns, the automation will create reporting noise faster than any manual workflow could.

That is why teams should review naming rules with the UTM tracking guide before scaling link creation through cURL or scripts.

2. Choose the fields that keep the request reusable

A strong cURL pattern is not the smallest possible payload. It is the smallest payload that still reflects your real workflow.

Depending on the use case, that can mean including fields such as:

  • destination URL
  • custom alias
  • branded domain
  • source, medium, and campaign parameters
  • campaign or channel grouping fields when relevant

OpenMyLink's public docs are useful because they show that link creation does not have to stop at the raw URL alone.

3. Plan for rate limits before batch jobs begin

OpenMyLink's public developer FAQ states a default rate limit of 30 requests per minute, with active values returned in the response headers.

That matters as soon as the team moves from one test request to:

  • launch-day batch creation
  • regional campaign generation
  • CRM-triggered link creation
  • scheduled scripts that fetch or create records repeatedly

A cURL proof-of-concept is the right place to learn those operational constraints early instead of discovering them after the automation is already attached to a live workflow.

4. Keep analytics in the design, not only in the next phase

A lot of teams automate link creation first and think about reporting later.

That usually leads to weak attribution because the created link lacks the fields and naming discipline needed for clean analysis. OpenMyLink's public analytics page and developer documentation matter here because they connect creation and reporting into the same product surface.

If the short link will eventually be reviewed by campaign, referrer, device, country, or QR performance, the cURL payload should already reflect the naming logic that makes those reports understandable.

5. Design for the next API task too

The most useful cURL workflow often expands beyond POST /api/url/add.

Once the team is comfortable with the request pattern, the next steps may include:

  • creating QR codes for the same campaign
  • fetching click or scan analytics
  • uploading a file behind a tracked branded URL
  • appending blocks to a bio page

OpenMyLink's API recipes are especially helpful because they show those adjacent operations with the same general auth and JSON model.

A simple operating pattern for teams

A durable cURL workflow usually follows this order:

  1. define campaign naming rules
  2. test one link request manually
  3. verify the returned short URL and metadata
  4. store the request pattern in a reusable script or template
  5. extend the same pattern into analytics, QR, or bio-page operations if needed

This keeps the process observable. It also makes troubleshooting easier because the raw request is still understandable without digging through a larger codebase.

Based on the current public product and docs surface, OpenMyLink is relevant for teams that want to connect:

That makes it a good fit for teams that want one API surface for more than a single redirect endpoint.

Final takeaway

Creating short links with cURL is useful because it exposes the workflow in its simplest form.

It helps your team verify authentication, payload design, campaign naming, and response handling before you hide those decisions inside a larger automation system.

If you are planning your first API-driven link workflow, compare OpenMyLink's developer API page, API recipes, and analytics page before writing the full integration. That is the practical next step from test request to durable operations.

Free to start · no credit card

Move from one-off API tests to an operational cURL workflow.

Start with link creation, then extend into QR codes, analytics, and campaign automation through the same OpenMyLink API surface.