Documentation menu

AussieSMS / stable contract

Build against the route that exists.

The current public contract is deliberately small: authenticate an account request, queue one Australian SMS, inspect the returned state, and query only message IDs owned by that API key.

Signal route / exampleAU-PKT-019
Static demo · not a live queue
AussieSMS signal routeREQUESTAPI key acceptedQUEUEDBalance checkedCLAIMEDGateway takes rowSENTCarrier attemptRECEIPTNot assumedAussieSMS signal routeREQUESTAPI key acceptedQUEUEDBalance checkedCLAIMEDGateway takes rowSENTCarrier attemptRECEIPTNot assumed
Delivery receipt · not assumed

Sent means the handset reported a carrier attempt. A receipt is a separate event and is not inferred from a successful send.

The contract in three boundaries

Account

Bearer or X-API-Key authentication maps every request to one user.

Queue

A successful POST means queued. One credit is charged at that boundary.

Status

Sent is a carrier attempt. Delivered requires separate receipt evidence.

01

Make one authenticated request

Replace the example number with an Australian mobile you are authorised to contact. This is a real send route, not a sandbox.

Bash|POST /api/gateway/send
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."
  }'

Safe testing boundary

AussieSMS does not expose an unauthenticated browser tester. Automated tests should mock the HTTP boundary. A manual integration check can send a real message and spend a credit, so run it only with authority to contact the recipient.