Prerequisites

Before registering your service, make sure you have:

• A valid APRS callsign / tactical address — 3–9 uppercase alphanumeric characters, optional -SSID (1–2 alphanumeric, not starting with 0), total length ≤ 9. Service names like REPEAT or WXBOT are fine; they do not need to be ITU amateur callsigns.
• A running APRS service — Your service should be operational and connected to APRS-IS
• A service website (optional) — A URL where users can learn more about your service

What happens after registration?

1. Your service is stored with status pending (visible on the site, but not yet proven alive).
2. The registry schedules a health-check probe to your callsign.
3. On the first successful response (ACK or reply message), status becomes active.
4. An admin can also set status manually.

Re-POSTing the same callsign (for example an APRSD heartbeat) updates description/website/software but does not change status, and cannot undelete a deleted service.

Registration Process

Register your service by sending an HTTP POST request to the registry API. You can do this manually, or configure your APRS software to do it automatically.

Required Fields

Optional Fields

Example Request

curl -X POST https://services.aprslive.com/api/v1/registry \
  -H "Content-Type: application/json" \
  -d '{
    "callsign": "REPEAT",
    "description": "Find the nearest N repeaters to your current location",
    "service_website": "http://aprs-repeat.hemna.com",
    "software": "APRSD version 3.3.0",
    "callsign_owner": "WB4BOR"
  }'

Using APRSD

If you're running APRSD version 3.3.0 or later, you can enable automatic registry updates in your configuration file:

[aprs_registry]
# Enable the automatic registry feature
enable = true

# The description of your service
description = My service does X, Y, and Z.

# The URL of your service
service_website = http://myaprsservice.com

# How often to update the registry (in seconds)
# Default: 900 (15 minutes)
frequency_seconds = 900

With this configuration, APRSD will automatically register and periodically update your service in the registry.

Health Checks

The registry automatically monitors registered services to track their availability.

How Health Checks Work

1. The registry sends a single APRS message (the "probe") to your service's callsign
2. Your service is considered alive as soon as the registry sees either an APRS ACK of that message or any reply message from your callsign
3. If nothing is received within the timeout, the check fails (the probe is sent only once — the registry does not retry)
4. Results are recorded and displayed as a heatmap on the service card

The Probe Command

The message the registry sends is configurable per service via the health_check_command field (see below). By default the registry sends ping. Because an ACK alone proves your service is alive, the ideal probe is one that your service simply acknowledges without sending a long reply — this keeps APRS RF traffic to a minimum.

Check Frequency

Each service is health-checked once per hour. Checks are staggered evenly across the hour (roughly one service every few seconds, depending on how many services are registered) so the registry never probes every service at once. The registry stores the last 24 results for the heatmap.

Status Transitions

• Active → Pending — Occurs after the first failed health check
• Pending → Active — Occurs when a health check passes
• Pending → Down — Occurs after 3 consecutive failed health checks
• Down → Active — Occurs when a health check passes

Choosing Your Health Check Command

You can tell the registry exactly what to send your service by setting the optional health_check_command field when you register or update. This lets you pick the command that produces the fewest response packets:

• APRSD-based services — Use ping. APRSD replies with an ACK and a single short pong, which is minimal and ideal.
• Other services — Choose a command that your service simply ACKs without a long reply. Avoid help or listing commands (like ?) as your health check — these often reply with several messages, flooding the APRS network on every check.

curl -X POST https://services.aprslive.com/api/v1/registry \
  -H "Content-Type: application/json" \
  -d '{
    "callsign": "MYCALL",
    "description": "My APRS service",
    "health_check_command": "ping"
  }'

Manual Health Check

You can manually trigger a health check for your service:

curl -X POST https://services.aprslive.com/api/v1/health-check/YOURCALL

Updating Your Service

To update your service information, POST to the same endpoint with the updated data. The callsign is the unique identifier. Description, website, and software are replaced; status is preserved (a heartbeat will not activate a pending service or undelete a deleted one). Health-check history is kept.

curl -X POST https://services.aprslive.com/api/v1/registry \
  -H "Content-Type: application/json" \
  -d '{
    "callsign": "MYCALL",
    "description": "Updated description",
    "service_website": "http://new-url.com",
    "software": "APRSD 3.4.0"
  }'

Removing Your Service

To remove your service from the registry, send a DELETE request:

curl -X DELETE https://services.aprslive.com/api/v1/registry/YOURCALL

This performs a "soft delete" — your service will be marked as deleted and hidden from the public listing, but the record is retained in case you want to re-register later.

Best Practices

• Implement a lightweight ping/pong command — Support a simple ping command that ACKs and replies with a single short pong (nothing more). Then set health_check_command to ping. This lets the registry confirm your service is alive in just one or two packets per hourly check, keeping APRS RF traffic to a minimum. APRSD does this out of the box.
• Keep health check responses minimal — Never point your health check at help or a listing command that returns several messages. A multi-message reply on every hourly check adds needless congestion to the shared APRS network.
• Keep your description concise — Aim for one or two sentences that clearly explain what your service does
• Provide a working website — Include documentation on how to use your service
• Update regularly — If using APRSD, enable automatic updates to keep your listing current
• Monitor health checks — Check your service's status periodically to ensure it's responding