Quickstart / real send boundary

Queue one message, then read what actually happened.

This flow uses a live authenticated route. It can spend one credit and cause a handset to attempt an SMS. Use a recipient you are authorised to contact.

Prepare the account

Sign in, create an API key, confirm a positive prepaid balance, and understand whether a gateway is online. An offline gateway can still leave the message queued.

Open API keys · Open credits

POST the request

Keep the API key in a server environment variable. Do not ship it to browser code or commit it to source.

Bash|Authenticated request

curl -X POST https://aussiesms.net/api/gateway/send \
  -H "Authorization: Bearer $AUSSIESMS_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"to":"+61400000000","message":"Your booking is confirmed."}'

Read the queue response

The returned message ID is the handle for later status checks. Queued is not a delivery receipt.

JSON|Example 200 response

{
  "success": true,
  "messageId": "00000000-0000-0000-0000-000000000000",
  "status": "queued",
  "to": "+61400000000",
  "creditsCharged": 1,
  "creditsRemaining": 499,
  "gatewayStatus": "online",
  "message": "SMS queued for a gateway send attempt"
}

Query an account-owned message

Status lookup requires the same account boundary and will not return a row owned by another API key user.

Bash|GET message status

curl "https://aussiesms.net/api/gateway/send?id=$MESSAGE_ID" \
  -H "Authorization: Bearer $AUSSIESMS_API_KEY"

Do not automate against the live rail

Integration tests should replace this endpoint with a local fake. Do not use a production API key or generate real SMS traffic as a build or health check.

HTTP clients, not fictional SDKs

There is no official AussieSMS SDK package in the current stable contract. Use the standard HTTP client for your language and preserve the request and response shape documented here.