Send Your First MMS with the intouch API

Three requests: get a token, send the message, trace it. This quickstart sends a real MMS — an image plus text — to an Australian mobile through the intouch API. You'll need API credentials (client ID and secret) and a dedicated virtual number, both provisioned with your account; the full endpoint reference is in the API overview and the interactive explorer at apimobiledigital.com.

Last reviewed: 22 August 2026.

1. Get a bearer token

curl -X POST "{BASE_URL}/token" \
  -H "Content-Type: application/x-www-form-urlencoded" \
  -d "grant_type=client_credentials" \
  -d "client_id={YOUR_CLIENT_ID}" \
  -d "client_secret={YOUR_CLIENT_SECRET}"

The response contains your access_token. Sanity-check it against the purpose-built validation endpoint before going further:

curl -X POST "{BASE_URL}/test-oauth2" \
  -H "Authorization: Bearer {ACCESS_TOKEN}"

A 200 means auth is working; a 403 means your token is valid but missing the write scope — check your credential's scope grant.

2. Prepare the media

MMS media travels base64-encoded in the request body, with the file type given as a bare extension (png, gif, mp4):

base64 -w 0 offer.png > offer.b64

Design guidance for what actually renders well on Australian handsets — practical size ceilings, format choice, animation — is in the MMS channel guide. Short version: keep it a few hundred kilobytes; PNG or GIF for stills and animation.

3. Send the MMS

curl -X POST "{BASE_URL}/sendMMS" \
  -H "Authorization: Bearer {ACCESS_TOKEN}" \
  -H "Content-Type: application/json" \
  -d '{
    "from": "{YOUR_DEDICATED_NUMBER}",
    "destination": "+61400000000",
    "subject": "Your welcome offer",
    "mms_text_content": "Hi! Here is 20% off your first order.",
    "content_type": "png",
    "media_content": "'"$(cat offer.b64)"'",
    "tracking_id": "first-mms-001"
  }'

Field notes:

• from — your dedicated virtual number. MMS in Australia always sends from a number, not an alphanumeric sender ID.
• destination — the recipient; +614… and 04… formats both route.
• tracking_id — your correlation ID, echoed through delivery reporting so you can join results to your own records.
• transactional — omit it for marketing sends. Setting true bypasses marketing opt-in checks and is reserved for genuinely transactional messages (the legal boundary matters).

A successful response returns the identifiers you'll use for everything downstream:

{ "result": true, "status": 200, "transId": "…", "log_uuid": "…" }

4. Trace delivery

curl -X POST "{BASE_URL}/traceTransactionId" \
  -H "Authorization: Bearer {ACCESS_TOKEN}" \
  -H "Content-Type: application/json" \
  -d '{ "transId": "{TRANS_ID_FROM_STEP_3}" }'

Polling is fine for a first test; production systems should use webhooks to receive delivery events push-style instead.

Troubleshooting