# Outbound API Parameter Notes
### Definitions
**Message Reference**
**`message_reference`** is a unique identifier you can set that allows you to differentiate your outbound calls from one another. This same parameter can be used by the start\_url to customize the call session.
**Call Parameters**
**`call_parameters`** allows you to send arbitrary data with possibly several different parameters sent in a single string.
**Max Retries**
**`max_retries`** allows you to set a maximum number of retries for attempting an outbound call before giving up. This number of retries can only be set to an integer between 0 and 10.
**Retry Interval**
**`retry_interval`** allows you to set the number of seconds in between retrying an outbound call. This number of seconds can be set to an integer between 60 and 172800.
**Scheduled Timestamp**
**`scheduled_timestamp`** allows you to set a UNIX-time integer indicating when to start attempting your outbound call. If you do not wish to use UNIX time, you can use the POST variable, scheduled\_time, to use simple natural time expressions like “now”, “oct 14th, 2011 11:05PM EST”, or “+3 days”.
**Expiration Timestamp**
**`expiration_timestamp`** allows you to set a UNIX-time integer indicating when to give up attempting your outbound call. If you do not wish to use UNIX time, you can use the POST variable, expiration\_time, to use simple natural time expressions like “now”, “oct 14th, 2011 11:05PM EST”, or “+3 days”.
### [Single Outbound Call](/dev/plum-dev-apis/dev-outbound-apis.md#queue-a-single-call)
Notes on `queuecall.php` form data parameters.
| Parameter(s) | Notes |
| ----------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| phone\_number
message\_reference
call\_parameters
| These parameters are stored and passed back to the application start\_url as POST variables. |
| **phone\_number** | To dial an extension number, the format is: tel:+16177123000;postd=1234. However, if you do outbound dialing to an extension, you would want to use a \ tag to account for the hold music that is played while you are being transferred to the extension and to ensure that your prompts are played at the correct time.
To specify the caller ID on a per call basis, you'll have to change your phone\_number parameter to also include the caller ID you want the call recipient to see. The format is: phone\_number=tel:+10123456789;ani=1234567890. This would make an outbound call to 012-345-6789 and display a caller ID of 123-456-7890.
The 'ani' must be a 10 digit number, without the preceding '1'. If it is not, the call will either be declined completely or it will go through with Plum's default caller ID (depending on which carrier(s) the call is routed through).
The 'tel' is a telephone URL as defined here: . You must include the '+' and then the country code before the number (so the above example would apply to all calls made within the US, where country code is '1').
|
| **start\_url** | The start\_url should return valid VoiceXML 2.0. When `queuecall.php` receives a POST the start\_url will be fetched once by either your server or the server hosting outbound.plumvoice.com. You will need to enable access from these IP Addresses or the POST to `queuecall.php` will timeout. |
| **result\_url** | Outbound system posts result either after all retry attempts have been made or after the call successfully completes. |
| message\_reference
call\_parameters
| Typically, the **`message_reference`** POST variable passes a single call identifying string that the start URL uses to customize the call session. The **`call_parameters`** POST variable is used for arbitrary data with possibly several different parameters sent in a single string. It is up to the user to format and parse the data within the **`call_parameters`** string. |
| scheduled\_timestamp
expiration\_timestamp
| Instead of using UNIX time to indicate the scheduled start and expiration timestamps, it may be easier to use simple natural language time expressions like “now”, “oct 14th, 2003 11:05PM EST”, or “+3 days”. Use the **`scheduled_time`** and **`expiration_time`** POST variables to take advantage of this capability. These two POST variables are strings of no more than 80 characters. |
### [Multiple Outbound Calls](/dev/plum-dev-apis/dev-outbound-apis.md#queue-multiple-calls)
Notes on `queuecalls.php` form data parameters.
| Parameter(s) | Notes |
| --------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| phone\_list
campaign\_parameters
| These parameters are stored and passed back to the application start\_url as POST variables. |
| **phone\_list** | Calls are listed in the phone number list file on [comma-delimited lines](/dev/plum-dev-apis/dev-outbound-apis/contacts-csv-formatting.md) where the first field is the phone number and the second and third fields are a **`message_reference`** string and **`call_parameters`** string for the call. The second and third fields are optional. |
| **start\_url** | The start\_url should return valid VoiceXML 2.0. When `queuecalls.php` receives a post, the start\_url will be fetched once by either your server or the server hosting outbound.plumvoice.com. You will need to enable access from these IP Addresses or the POST to `queuecalls.php` will timeout. |
| **result\_url** | Outbound system posts result either after all retry attempts have been made or after the call successfully completes. |
| **campaign\_parameters** | The **`campaign_parameters`** POST var is used for arbitrary data with possibly several different parameters sent in a single string. It is up to you to format and parse the data within the **`call_parameters`** string. |
| scheduled\_timestamp
expiration\_timestamp
| Instead of using UNIX time to indicate the scheduled start and expiration timestamps, it may be easier to use simple natural language time expressions like “now”, “oct 14th, 2003 11:05PM EST”, or “+3 days”. Use the **`scheduled_time`** and **`expiration_time`** POST variables to take advantage of this capability. These two POST variables are strings of no more than 80 characters. |
---
# Agent Instructions: Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter:
```
GET https://docs.plumvoice.com/dev/plum-dev-apis/dev-outbound-apis/outbound-api-parameter-notes.md?ask=
```
The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.