Test (sandbox) accounts for API development

Updated 19 August 2026 · 104 views

A test (sandbox) account lets you build and test an API integration against the real Mobile Message API without any live sending. Test accounts are available on request. Email hello@mobilemessage.com.au and we'll set one up for you.

How a test account behaves

A test account works exactly like a live account at the API level, with sending disconnected:

  • Requests are validated and answered exactly as on a live account. You receive real message_id values, per-message results, and cost calculations in responses.
  • No messages are ever delivered to handsets, and no credits are consumed.
  • Accepted messages are recorded with a final status, so message lookup flows can be exercised end to end. Scheduled messages are released at their scheduled time.
  • Contacts, lists, unsubscribes, idempotency keys and the other account endpoints behave exactly as live.

This makes a test account safe for CI. Your integration tests can run against the real API with no risk of live SMS traffic or charges.

Delivery receipt webhooks

Delivery receipt webhooks fire for test sends. Around 5 seconds after a message is accepted, a simulated delivery receipt is posted to your status webhook URL with the same payload as a real one, one webhook per message part. Set up your webhook URLs the normal way, see Setting up webhooks. If your account has a signing secret, simulated webhooks are signed exactly like real ones.

To test your failure handling, send to any number ending in 000 (for example 0412345000). That message is recorded as failed and its delivery receipt reports failed. All other test messages are reported as delivered.

Simulating inbound messages

Test accounts can simulate a reply with POST /v1/test-inbound. This records the inbound message on your account exactly as a real reply would, including opt-out processing when the message starts with STOP, and posts to your inbound webhook URL if one is set.

FieldTypeDescription
fromStringThe mobile number the reply comes from (required).
messageStringThe reply content (required). Start it with STOP to simulate an opt-out.
toStringWhich of your sender IDs received the reply (optional). Defaults to the sender of the last message you sent to that number.
 
curl -u user123:mypassword \
  -H "Content-Type: application/json" \
  -d '{"from": "0412345678", "message": "Thanks, see you then!"}' \
  https://api.mobilemessage.com.au/v1/test-inbound

Response:

{ "status": "success", "type": "inbound", "to": "YourBrand", "from": "61412345678", "webhook_queued": true }

type is unsubscribe when the message was treated as an opt-out. The inbound webhook payload is identical to a real inbound message, including original_message_id and original_custom_ref when the reply matches a message you previously sent to that number.

The endpoint returns 403 on live accounts and allows up to 100 simulated inbound messages per hour.

Good to know

  • A real dedicated number can't be attached to a test account, because nothing reaches the carrier network. Two-way flows are still fully testable with the simulated inbound endpoint above.
  • ACMA sender ID registration is not available on test accounts. Registrations are lodged with the real ACMA register, so they can only be submitted from a live account.
  • The webhooks page in your dashboard shows the delivery log for simulated webhooks the same way it does for real ones, see Webhook delivery logs.
  • The full API reference, including the test account section, is at mobilemessage.com.au/api-documentation.

Related Articles