Send Android Notifications with curl
Try a manual notification from your terminal before adding notifications to automation.
QuickStart
Needs: Bash + curl
- Install QueueRing on Android, register the device, allow notifications, and copy the current Queue ID. Keep the phone online.
- Paste into Bash, then enter your Queue ID at the hidden prompt.
- Verify on your device
Queue ID grants permission to send: keep it secret. If leaked, reissue it in the app and update your configuration. Security details.
202 only means accepted; display, history, and ID validity are not guaranteed. Resends can duplicate alerts; retry the notification only, never the job or agent. HTTP errors and retry advice.
(
set +x
set -eu
read -r -s -p 'Paste the Queue ID from your Android app: ' QUEUE_ID
printf '\n'
set +x
: "${QUEUE_ID:?Load your Queue ID before sending}"
[[ "$QUEUE_ID" =~ ^qr1\.[A-Za-z0-9_-]{1,16}\.[A-Za-z0-9_-]{59}$ ]] || {
printf 'Invalid Queue ID format; copy it from the app.\n' >&2
exit 1
}
message=$(printf '%s\n' 'Deployment completed' 'Check the release on Android.')
status=$(curl --silent --connect-timeout 10 --max-time 30 \
--output /dev/null --dump-header /dev/stderr --write-out '%{http_code}' \
--request POST "https://api.queuering.org/q/$QUEUE_ID" \
--header 'Content-Type: text/plain; charset=utf-8' \
--data-binary "$message") || {
printf 'Notification transport failed; check connectivity.\n' >&2
exit 1
}
printf 'Notification HTTP %s\n' "$status" >&2
[[ "$status" == 202 ]]
)Copy buttons copy code only. If unavailable, select the code and copy manually. Code messages are shared with the English examples.
Verify on your device
Expect HTTP 202 and a notification containing two lines, starting with Deployment completed. Open QueueRing and check whether the message was captured in recent history.
If HTTP 202 arrives without a phone alert, verify the current Queue ID, Android notification permission, and device connectivity first. Check the app's recent history as an additional observation, not a delivery receipt.
More examples and integration limits
Integration steps and limits
Bash and curl on Linux or macOS, plus an internet connection.
Send JSON with a title
Paste this independent Bash example and enter your Queue ID at the hidden prompt. JSON requires a nonempty body; title is optional and must be nonblank when supplied. The single-quoted literal preserves JSON escapes for quotes and a newline. For dynamic values, use a JSON encoder such as jq or JSON.stringify instead of string concatenation.
(
set +x
set -eu
read -r -s -p 'Paste the Queue ID from your Android app: ' QUEUE_ID
printf '\n'
set +x
: "${QUEUE_ID:?Load your Queue ID before sending}"
[[ "$QUEUE_ID" =~ ^qr1\.[A-Za-z0-9_-]{1,16}\.[A-Za-z0-9_-]{59}$ ]] || {
printf 'Invalid Queue ID format; copy it from the app.\n' >&2
exit 1
}
status=$(curl --silent --connect-timeout 10 --max-time 30 \
--output /dev/null --dump-header /dev/stderr --write-out '%{http_code}' \
--request POST "https://api.queuering.org/q/$QUEUE_ID" \
--header 'Content-Type: application/json' \
--data-binary '{"title":"Build finished","body":"Result: \"success\"\nReady to review."}') || {
printf 'Notification transport failed; check connectivity.\n' >&2
exit 1
}
printf 'Notification HTTP %s\n' "$status" >&2
[[ "$status" == 202 ]]
)Check HTTP 202 and the title Build finished on your phone. This literal example requires no JSON encoder.
Queue ID security details
Keep the Queue ID private
A Queue ID grants permission to send notifications to your device: treat it as a bearer credential. Never put a real ID in public repositories, Issues, logs, screenshots, prompts, or fixed sample values. Do not use shell tracing (set -x), curl verbose/trace output, or shared terminal recordings. The URL and process arguments can contain the ID; run only on a trusted machine and restrict proxy/access logs.
If exposed, reissue/rotate the Queue ID in the app and replace every local configuration or Actions secret using the old ID. Copy the new value from the app rather than editing the old one. A 202 response cannot confirm that an old ID remains valid.
API contract, HTTP errors, and retries
Understand the response and retry safely
Notifications and message history are best-effort. HTTP 202 means request acceptance, not guaranteed display on Android or guaranteed history storage. Invalid, inactive, and outdated Queue IDs intentionally receive the same 202 response. History stores up to 100 messages captured on the device; absence from history alone does not establish an HTTP failure.
The endpoint is POST https://api.queuering.org/q/{queueId}. Use UTF-8 text/plain; charset=utf-8, or application/json with a required nonempty body string and optional nonblank title. The raw request body, including JSON syntax, must be at most 4096 bytes.
| Result | What to do |
|---|---|
| 202 | Check Android notification permissions, connectivity, and the current ID in the app. Do not retry merely because no notification appears. |
| 400 | Fix the request, Content-Type, JSON syntax, and required fields before resending. |
| 413 | Shorten the UTF-8 body to 4096 bytes or less; JSON escaping also counts. |
| 429 | Wait at least Retry-After seconds when provided. If absent, use a delayed bounded retry with backoff rather than a tight loop. |
| 503 | Temporarily unavailable. Inspect the failure and retry later with bounded backoff. |
| Transport failure / timeout | The outcome may be unknown. Check connectivity before deciding to resend. |
The samples send once, with a 10-second connect timeout and 30-second total timeout. They print HTTP status and response headers (including Retry-After), and do not automatically retry. Resending can create duplicate alerts; there is no idempotency key in these examples. Retry the notification only, never rerun a backup, deployment, or agent just to send its status. Keep your normal job logs and monitoring as the source of truth.