# MM7_Submit
Send a MMS message to end users trough the Sinch MM7 API. Read more.
**Send MMS MT to end users**
To send a multimedia message, you send an MT message as a submit request to Sinch and supply the multimedia message as the payload. When Sinch accepts your MT message, we respond to you with a success status using "SubmitRsp" response. This indicates that your message was accepted for delivery. It doesn't, however, indicate that your message was delivered to the device. If the MT message was received in error, we respond to you with a failure status using SOAP fault "RSErrorRsp" response.
Group Messaging, also referred to as Group Chat, is enabled by utilizing the `displayOnly` attribute within the `number` node. To send multimedia messages to multiple recipients, one recipient's `displayOnly` attribute must be set to `false`, while the others' attributes should be set to `true`. If the attribute is set to `false` for more than one recipient, the API request will be declined with Status code 2572. If it's set to `true` for all recipients, the request will be declined with Status code 2571. The attribute only accepts `true` or `false`, with `false` being the default setting. Please refer to the status code sections for more status-related information.
It's important to note that group messaging operates as a pass-through, ensuring delivery only to the recipient with the `displayOnly` attribute set to `false`. To ensure delivery to all recipients, multiple requests must be made for each recipient with the Number's `displayOnly` attribute set to `false`.
Note:
This feature is only available for Sinch 10DLC MMS offering for US Wireless carriers: AT&T, T-Mobile US, Verizon Wireless, U.S. Cellular, and Google Voice.
**Using the mobile operator ID in an MM7 request - (Standard MMS Only)**
You can supply the mobile operator details as an ID in the request header of an MM7 "SubmitReq" request. If you don't supply the mobile operator, Sinch would look it up (this may be a separately charged fee, depending on your contract). The same mobile operator ID is returned in the HTTP header of delivery reports and MO requests. For the best throughput performance, you should include the mobile operator ID in each request, otherwise an operator lookup is needed before we can forward the message to the mobile operator.
| Header Name | Description | Mandatory |
| --- | --- | --- |
| X-Mblox-Carrier-Id | Sinch Mobile Operator ID.Examples: AT&T=0001470, Verizon=0001890.See all [Sinch operator IDs](/docs/mms/7-service/sinch-operator-ids). | No |
**SMIL is Required**
SMIL is required in all the SubmitReq MM7 Requests. SMIL is an XML based language to write interactive multimedia presentations. For more information about SMIL, see [the World Wide Web Consortium's document on SMIL](https://www.w3.org/TR/SMIL/).
## MM7_Submit.REQ
**Supported MM7 SOAP envelope request elements**
| | | |
| --- | --- | --- |
| **Element** | **Description** | **Mandatory** |
| TransactionID | The identification of the MM7 SubmitReq/SubmitRsp pair. It's located in,the SOAP header. You supply this in the MM7 SubmitReq and Sinch returns,it in the corresponding SubmitRsp. | Yes |
| SubmitReq | Identifies the message as an MMS MT submit. This is the message type for an MT request. | Yes |
| MM7Version | Identifies the MM7 Version.(Supported versions are ver-5.3.0 and ver-6.8.0) | Yes |
| VASPID | Sinch provides an API key after your account is provisioned which is your VASPID. | Yes |
| VASID | Your account manager will provide you with a VASID for each shortcode. It's mandatory for accounts using shared shortcodes, otherwise optional. | No |
| SenderAddress | This is your shortcode. Should be provisioned and configured to your account and service. | Yes |
| Recipients | The mobile phone number of the end user. This must be a valid mobile,number in international format without a leading + symbol; for example: 12515550123 (US) and 447700900750 (UK). Multiple numbers are NOT supported. | Yes |
| Subject | Title of the whole multimedia message. Recommended size is 80 characters. See the [special considerations](#special-considerations-for-mm7_submitreq) section for information on character restrictions. | No |
| Content | Content of the multimedia message. href:cid attribute links to attachment. | Yes |
| allowAdaptations | Indicates if you wish to allow the mobile operator to re-encode (transcode) the content to make the content more suitable to the target handset. Each mobile operator may choose to obey or ignore this field; for example, some mobile operators assume or require by default the,option to transcode content. AllowAdaptations is an attribute of Content element. The value must be Boolean (either true or false). The default is true. | No |
| DeliveryReport | A request for delivery report. Boolean value true/false. Defaults value is true. | No |
| ExpiryDate | The desired time of expiry for the MM (time stamp). Date format is absolute. Default value is 3 days. | No |
See [unsupported elements for MM7_Submit](/docs/mms/7-service/unsupported-mm7-soap-elements/).
**Example**
Example 1
```xml
1000001
6.8.0
skfdjslkjfdslkfj434das
126273
111122
16172383232
My first MM7 Message
```
Example 2 (Group Messaging)
```xml
1000001
6.8.0
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
00000
10000000001
10000000002
10000000003
My first MM7 Group Message
```
## MM7_Submit.RES
**Supported MM7 SOAP envelope response elements**
| | |
| --- | --- |
| **Element** | **Description** |
| TransactionID | The identification of the MM7 SubmitReq/SubmitRsp pair. It's located in the SOAP header. You supply this in the MM7 SubmitReq and, Sinch returns it in the corresponding SubmitRsp. |
| SubmitRsp | Identifies the message as a MM7 Submit Response. This is the message type for an MT response. |
| MM7Version | Identifies the MM7 Version.(Supported versions are ver-5.3.0 and ver-6.8.0) |
| StatusCode | MT message submit accepted/rejected is based on Success/Failure status code. “Success” response doesn't mean the message was delivered to the handset. See all [MMS status codes](/docs/mms/7-service/mms-status-codes/). |
| StatusText | Description of the status code. |
| MessageId | If the MT message submit's successful then this contains the Sinch generated ID of the submitted message. This ID is expected in the delivery reports relating to this message. |
**Example: Success**
```xml
1000001
6.8.0
1000
Successfully parsed and validated request
369500617770864640
```
**Example: Failure**
```xml
1000001
soap-env:Client
Client error
6.8.0
2007
Unable to parse request
Message format corrupt
```
## MT Submit Full Example
**Request:**
```text
POST /mm7/v1 HTTP/1.1
Authorization: Basic dW5pdmyc2FsLXZhcj2YWwtdmFzcC1wd2Q=
Host: api.Mblox.com
Accept: */*
Content-Type: multipart/related; boundary="mainBoundary"; type="text/xml"; start=""
SOAPAction: "http://www.3gpp.org/ftp/Specs/archive/23_series/23.140/schema/REL-6-MM7-1-4"
Content-Length: 45454
X-Mblox-Carrier-Id: 0001890
Expect: 100-continue
--mainBoundary
Content-Type: text/xml; charset=utf-8
Content-ID:
555e29f8879be
6.8.0
true
spUsdstW2u6GbvnMOsdseXrBa7NNLwTdKL
61295
111122
16179593069
My first MM7 Message
2015-05-24T18:54:48+00:00
2015-05-21T18:54:48+00:00
--mainBoundary
Content-Type: multipart/related; start="";
boundary="subBoundary"; type="text/xml"
Content-ID:
--subBoundary
Content-Type: text/plain; charset=utf-8
Content-ID: <132c4ca56a209475>
MM7 Test Text
--subBoundary
Content-Type: application/smil; charset=utf-8
Content-ID:
--subBoundary--
--mainBoundary--
```
**Response:**
```text
HTTP/1.1 200 OK
Content-Type: application/xml; charset=utf-8
Date: Mon, 16 Mar 2015 17:46:59 GMT
Server: Apache
Vary: Accept-Encoding,User-Agent
Content-Length: 715
Connection: keep-alive
1000001
6.8.0
1000
Successfully parsed and validated request
369500617770864640
```
## Special Considerations for MM7_Submit.REQ
The `Subject` parameter should not contain emoji/Unicode characters as this will cause messages to get rejected by the carrier's MMSC.
Additionally, the `Subject` parameter should not contain any of the following special characters: `<`, `>`,`&`, `'`, or `"`. Including any of these characters will cause the message to be rejected. Instead, use the XML character entity name, which will allow the character to display correctly in the message:
| Entity Name | Description | Rendered Text |
| --- | --- | --- |
| `<` | Less than | < |
| `>` | Greater than | > |
| `&` | Ampersand | & |
| `'` | Single quotation mark (apostrophe) | ' |
| `"` | Double quotation mark | " |