Frequently Asked Questions

Common questions and troubleshooting help.

Common Issues at a Glance

  • Service not showing as active? — New registrations start as pending until the first successful health check
  • Service shows as down? — Ensure your service is connected to APRS-IS and responding to messages
  • Registration rejected (400)? — Check the callsign matches APRS address rules (3–9 chars, optional SSID)

General Questions

What is this site?

The APRS Service Registry is a public directory of APRS message-based services. It helps ham radio operators discover available services and helps service operators make their services visible to the community.

Is this an official APRS resource?

No, this is a community-maintained project. It is not affiliated with any official APRS organization, though it aims to be a useful resource for the APRS community.

How often is the data updated?

Service registrations are updated immediately when operators POST new data. Health checks run hourly for all registered services, so status information is typically less than an hour old.

Is this service free?

Yes, the APRS Service Registry is completely free to use for both browsing and registration. There are no fees or premium tiers.

Can I contribute to this project?

Yes! The project is open source. You can contribute code, report bugs, or suggest features via the GitHub repository.

For Operators

Why isn't my service showing up?

Check the following:

  • Verify your registration request was successful (you should get a {"status": "ok"} response)
  • Confirm the callsign is valid (APRS tactical address rules; invalid callsigns return HTTP 400)
  • New services start as pending — they still appear on the public site, but status is pending until the first successful health check
  • Services with "deleted" status are hidden from the public listing

Why is my new service pending?

As of v1.13.0, brand-new registrations are stored as pending until a successful health check promotes them to active (or an admin changes the status). Re-POSTing the same callsign (APRSD heartbeat) does not change status by itself.

How do I update my service information?

POST to the registration endpoint again with the same callsign. Description, website, and software are updated. Status and admin-managed fields (commands, featured flag) are preserved. Deleted services stay deleted until an admin restores them.

What happens if health checks fail?

When health checks fail, your service status changes:

  1. First failure: Status changes from "active" to "pending"
  2. Continued failures: After 3 consecutive failures, status changes to "down"
  3. Recovery: When a health check passes, status returns to "active"

Services are never automatically deleted due to health check failures.

How do I remove my service from the registry?

Send a DELETE request to /api/v1/registry/{your-callsign}. This performs a soft delete—your service will be hidden from the public listing but the record is retained.

Can I re-register after deleting?

No. Soft-deleted services cannot be restored by POSTing again. Contact a maintainer / use the admin UI to undelete.

What callsign formats are accepted?

APRS tactical addresses: 3–9 uppercase letters/digits, optional hyphen + 1–2 character SSID (SSID must not start with 0), total length ≤ 9. Examples: REPEAT, WXBOT, WHO-IS, WB4BOR-11.

How do health checks actually work?

The registry sends an APRS message to your service's callsign via APRS-IS. If your service sends any response message within the timeout period (typically 60 seconds), the check passes. The registry does not validate the content of the response—any response indicates the service is alive.

For Developers

Is there rate limiting?

Yes. API endpoints are rate-limited to 60 requests per minute per IP (via slowapi). Please:

  • Cache responses where appropriate
  • Avoid polling more frequently than once per minute
  • Consider using the service count to detect changes instead of fetching all data

Can I use this data in my application?

Yes! The API is public and the data is freely available. We encourage building applications that help the APRS community. Attribution is appreciated but not required.

Is there a webhook or push notification system?

Not currently. The API is pull-based only. Webhooks for change notifications may be added in the future.

What's the best way to get notified of new services?

Poll the /api/v1/registry endpoint periodically and compare the count field to detect additions. For real-time needs, consider polling every few minutes.

How do I report a bug or request a feature?

Open an issue on the project's GitHub repository. Please include as much detail as possible, including steps to reproduce for bugs.

Health Check Questions

What do the colored dots mean?

The heatmap shows the last 24 health check results:

  • Green — Health check passed (service responded)
  • Red — Health check failed (no response or error)
  • Gray — No data (check hasn't run yet for this hour)

How is uptime calculated?

Uptime is calculated as the percentage of successful health checks over the last 24 hours. For example, if 20 out of 24 checks passed, uptime would be ~83%.

If fewer than 24 checks have been recorded (new services), uptime is calculated based on available data.

Why does my service show as unhealthy?

Common reasons for failed health checks:

  • Not connected to APRS-IS — Your service needs an active APRS-IS connection to receive messages
  • Not responding to messages — Your service must send a reply to incoming messages
  • Response too slow — Responses must arrive within the timeout period (typically 60 seconds)
  • Wrong callsign — The response must come from the registered callsign
  • Network issues — Temporary APRS-IS connectivity problems can cause false failures

Can I trigger a health check manually?

Yes! POST to /api/v1/health-check/{callsign} to immediately check a specific service. This is useful for testing after making changes to your service.

My service responded but the check still failed. Why?

Possible reasons:

  • Response was sent to a different callsign than the check originated from
  • Response took longer than the timeout period
  • Network routing issues caused the response to not reach the registry
  • Response was malformed or truncated

Still Have Questions?

If your question isn't answered here: