Twilio
Since Camel 2.20
Both producer and consumer are supported
The Twilio component provides access to Version 2010-04-01 of Twilio REST APIs accessible using Twilio Java SDK.
Maven users will need to add the following dependency to their pom.xml for this component:
<dependency>
<groupId>org.apache.camel</groupId>
<artifactId>camel-twilio</artifactId>
<version>${camel-version}</version>
</dependency>
Twilio Options
The Twilio component supports 8 options, which are listed below.
Name | Description | Default | Type |
---|---|---|---|
configuration (common) |
To use the shared configuration |
TwilioConfiguration |
|
bridgeErrorHandler (consumer) |
Allows for bridging the consumer to the Camel routing Error Handler, which mean any exceptions occurred while the consumer is trying to pickup incoming messages, or the likes, will now be processed as a message and handled by the routing Error Handler. By default the consumer will use the org.apache.camel.spi.ExceptionHandler to deal with exceptions, that will be logged at WARN or ERROR level and ignored. |
false |
boolean |
lazyStartProducer (producer) |
Whether the producer should be started lazy (on the first message). By starting lazy you can use this to allow CamelContext and routes to startup in situations where a producer may otherwise fail during starting and cause the route to fail being started. By deferring this startup to be lazy then the startup failure can be handled during routing messages via Camel’s routing error handlers. Beware that when the first message is processed then creating and starting the producer may take a little time and prolong the total processing time of the processing. |
false |
boolean |
autowiredEnabled (advanced) |
Whether autowiring is enabled. This is used for automatic autowiring options (the option must be marked as autowired) by looking up in the registry to find if there is a single instance of matching type, which then gets configured on the component. This can be used for automatic configuring JDBC data sources, JMS connection factories, AWS Clients, etc. |
true |
boolean |
restClient (advanced) |
Autowired To use the shared REST client |
TwilioRestClient |
|
accountSid (security) |
The account SID to use. |
String |
|
password (security) |
Auth token for the account. |
String |
|
username (security) |
The account to use. |
String |
The Twilio endpoint is configured using URI syntax:
twilio:apiName/methodName
with the following path and query parameters:
Path Parameters (2 parameters):
Name | Description | Default | Type |
---|---|---|---|
apiName |
Required What kind of operation to perform. There are 56 enums and the value can be one of: ACCOUNT, ADDRESS, APPLICATION, AVAILABLE_PHONE_NUMBER_COUNTRY, CALL, CONFERENCE, CONNECT_APP, INCOMING_PHONE_NUMBER, KEY, MESSAGE, NEW_KEY, NEW_SIGNING_KEY, NOTIFICATION, OUTGOING_CALLER_ID, QUEUE, RECORDING, SHORT_CODE, SIGNING_KEY, TOKEN, TRANSCRIPTION, VALIDATION_REQUEST, ADDRESS_DEPENDENT_PHONE_NUMBER, AVAILABLE_PHONE_NUMBER_COUNTRY_LOCAL, AVAILABLE_PHONE_NUMBER_COUNTRY_MOBILE, AVAILABLE_PHONE_NUMBER_COUNTRY_TOLL_FREE, CALL_FEEDBACK, CALL_FEEDBACK_SUMMARY, CALL_NOTIFICATION, CALL_RECORDING, CONFERENCE_PARTICIPANT, INCOMING_PHONE_NUMBER_LOCAL, INCOMING_PHONE_NUMBER_MOBILE, INCOMING_PHONE_NUMBER_TOLL_FREE, MESSAGE_FEEDBACK, MESSAGE_MEDIA, QUEUE_MEMBER, RECORDING_ADD_ON_RESULT, RECORDING_TRANSCRIPTION, RECORDING_ADD_ON_RESULT_PAYLOAD, SIP_CREDENTIAL_LIST, SIP_DOMAIN, SIP_IP_ACCESS_CONTROL_LIST, SIP_CREDENTIAL_LIST_CREDENTIAL, SIP_DOMAIN_CREDENTIAL_LIST_MAPPING, SIP_DOMAIN_IP_ACCESS_CONTROL_LIST_MAPPING, SIP_IP_ACCESS_CONTROL_LIST_IP_ADDRESS, USAGE_RECORD, USAGE_TRIGGER, USAGE_RECORD_ALL_TIME, USAGE_RECORD_DAILY, USAGE_RECORD_LAST_MONTH, USAGE_RECORD_MONTHLY, USAGE_RECORD_THIS_MONTH, USAGE_RECORD_TODAY, USAGE_RECORD_YEARLY, USAGE_RECORD_YESTERDAY |
TwilioApiName |
|
methodName |
Required What sub operation to use for the selected operation. There are 5 enums and the value can be one of: create, delete, fetch, read, update |
String |
Query Parameters (21 parameters):
Name | Description | Default | Type |
---|---|---|---|
inBody (common) |
Sets the name of a parameter to be passed in the exchange In Body |
String |
|
bridgeErrorHandler (consumer) |
Allows for bridging the consumer to the Camel routing Error Handler, which mean any exceptions occurred while the consumer is trying to pickup incoming messages, or the likes, will now be processed as a message and handled by the routing Error Handler. By default the consumer will use the org.apache.camel.spi.ExceptionHandler to deal with exceptions, that will be logged at WARN or ERROR level and ignored. |
false |
boolean |
sendEmptyMessageWhenIdle (consumer) |
If the polling consumer did not poll any files, you can enable this option to send an empty message (no body) instead. |
false |
boolean |
exceptionHandler (consumer) |
To let the consumer use a custom ExceptionHandler. Notice if the option bridgeErrorHandler is enabled then this option is not in use. By default the consumer will deal with exceptions, that will be logged at WARN or ERROR level and ignored. |
ExceptionHandler |
|
exchangePattern (consumer) |
Sets the exchange pattern when the consumer creates an exchange. There are 3 enums and the value can be one of: InOnly, InOut, InOptionalOut |
ExchangePattern |
|
pollStrategy (consumer) |
A pluggable org.apache.camel.PollingConsumerPollingStrategy allowing you to provide your custom implementation to control error handling usually occurred during the poll operation before an Exchange have been created and being routed in Camel. |
PollingConsumerPollStrategy |
|
lazyStartProducer (producer) |
Whether the producer should be started lazy (on the first message). By starting lazy you can use this to allow CamelContext and routes to startup in situations where a producer may otherwise fail during starting and cause the route to fail being started. By deferring this startup to be lazy then the startup failure can be handled during routing messages via Camel’s routing error handlers. Beware that when the first message is processed then creating and starting the producer may take a little time and prolong the total processing time of the processing. |
false |
boolean |
backoffErrorThreshold (scheduler) |
The number of subsequent error polls (failed due some error) that should happen before the backoffMultipler should kick-in. |
int |
|
backoffIdleThreshold (scheduler) |
The number of subsequent idle polls that should happen before the backoffMultipler should kick-in. |
int |
|
backoffMultiplier (scheduler) |
To let the scheduled polling consumer backoff if there has been a number of subsequent idles/errors in a row. The multiplier is then the number of polls that will be skipped before the next actual attempt is happening again. When this option is in use then backoffIdleThreshold and/or backoffErrorThreshold must also be configured. |
int |
|
delay (scheduler) |
Milliseconds before the next poll. |
500 |
long |
greedy (scheduler) |
If greedy is enabled, then the ScheduledPollConsumer will run immediately again, if the previous run polled 1 or more messages. |
false |
boolean |
initialDelay (scheduler) |
Milliseconds before the first poll starts. |
1000 |
long |
repeatCount (scheduler) |
Specifies a maximum limit of number of fires. So if you set it to 1, the scheduler will only fire once. If you set it to 5, it will only fire five times. A value of zero or negative means fire forever. |
0 |
long |
runLoggingLevel (scheduler) |
The consumer logs a start/complete log line when it polls. This option allows you to configure the logging level for that. There are 6 enums and the value can be one of: TRACE, DEBUG, INFO, WARN, ERROR, OFF |
TRACE |
LoggingLevel |
scheduledExecutorService (scheduler) |
Allows for configuring a custom/shared thread pool to use for the consumer. By default each consumer has its own single threaded thread pool. |
ScheduledExecutorService |
|
scheduler (scheduler) |
To use a cron scheduler from either camel-spring or camel-quartz component. Use value spring or quartz for built in scheduler |
none |
Object |
schedulerProperties (scheduler) |
To configure additional properties when using a custom scheduler or any of the Quartz, Spring based scheduler. |
Map |
|
startScheduler (scheduler) |
Whether the scheduler should be auto started. |
true |
boolean |
timeUnit (scheduler) |
Time unit for initialDelay and delay options. There are 7 enums and the value can be one of: NANOSECONDS, MICROSECONDS, MILLISECONDS, SECONDS, MINUTES, HOURS, DAYS |
MILLISECONDS |
TimeUnit |
useFixedDelay (scheduler) |
Controls if fixed delay or fixed rate is used. See ScheduledExecutorService in JDK for details. |
true |
boolean |
API Parameters (56 APIs):
The Twilio endpoint is an API based component and has additional parameters based on which API name and API method is used. The API name and API method is located in the endpoint URI as the apiName/methodName path parameters:
twilio:apiName/methodName
There are 56 API names as listed in the table below:
API Name | Type | Description |
---|---|---|
account |
Both |
|
address |
Both |
|
address-dependent-phone-number |
Both |
|
application |
Both |
|
available-phone-number-country |
Both |
|
available-phone-number-country-local |
Both |
|
available-phone-number-country-mobile |
Both |
|
available-phone-number-country-toll-free |
Both |
|
call |
Both |
|
call-feedback |
Both |
|
call-feedback-summary |
Both |
|
call-notification |
Both |
|
call-recording |
Both |
|
conference |
Both |
|
conference-participant |
Both |
|
connect-app |
Both |
|
incoming-phone-number |
Both |
|
incoming-phone-number-local |
Both |
|
incoming-phone-number-mobile |
Both |
|
incoming-phone-number-toll-free |
Both |
|
key |
Both |
|
message |
Both |
|
message-feedback |
Both |
|
message-media |
Both |
|
new-key |
Both |
|
new-signing-key |
Both |
|
notification |
Both |
|
outgoing-caller-id |
Both |
|
queue |
Both |
|
queue-member |
Both |
|
recording |
Both |
|
recording-add-on-result |
Both |
|
recording-add-on-result-payload |
Both |
|
recording-transcription |
Both |
|
short-code |
Both |
|
signing-key |
Both |
|
sip-credential-list |
Both |
|
sip-credential-list-credential |
Both |
|
sip-domain |
Both |
|
sip-domain-credential-list-mapping |
Both |
|
sip-domain-ip-access-control-list-mapping |
Both |
|
sip-ip-access-control-list |
Both |
|
sip-ip-access-control-list-ip-address |
Both |
|
token |
Both |
|
transcription |
Both |
|
usage-record |
Both |
|
usage-record-all-time |
Both |
|
usage-record-daily |
Both |
|
usage-record-last-month |
Both |
|
usage-record-monthly |
Both |
|
usage-record-this-month |
Both |
|
usage-record-today |
Both |
|
usage-record-yearly |
Both |
|
usage-record-yesterday |
Both |
|
usage-trigger |
Both |
|
validation-request |
Both |
Each API is documented in the following sections to come.
API: account
Both producer and consumer are supported
The account API has 2 method(s) which is represented by the following method signatures (an API method may have multiple signatures due to overloading):
com.twilio.rest.api.v2010.AccountFetcher fetcher();
com.twilio.rest.api.v2010.AccountFetcher fetcher(String pathSid);
com.twilio.rest.api.v2010.AccountUpdater updater();
com.twilio.rest.api.v2010.AccountUpdater updater(String pathSid);
The account API is defined in the syntax as follows:
twilio:account/methodName?[parameters]
The 2 method(s) is listed in the table below. (API methods can have a shorthand alias name which can be used in the syntax instead of the name)
Method | Alias | Description |
---|---|---|
fetcher |
fetch |
Create a AccountFetcher to execute fetch |
updater |
update |
Create a AccountUpdater to execute update |
The account API method(s) has the following set of parameters listed in the table below:
Method | Parameter | Description | Type |
---|---|---|---|
fetcher |
pathSid |
Fetch by unique Account Sid |
String |
updater |
pathSid |
Update by unique Account Sid |
String |
In addition to the parameters above, the account API can also use from the 21 endpoint query option which is listed in the Query Parameters section.
Any of the parameters can be provided in either the endpoint URI, or dynamically in a message header.
The message header name must be of the format CamelTwilio.parameter
.
The inBody
parameter overrides message header, i.e. the endpoint parameter inBody=myParameterNameHere
would override a CamelTwilio.myParameterNameHere
header.
API: address
Both producer and consumer are supported
The address API has 5 method(s) which is represented by the following method signatures (an API method may have multiple signatures due to overloading):
com.twilio.rest.api.v2010.account.AddressCreator creator(String customerName, String street, String city, String region, String postalCode, String isoCountry);
com.twilio.rest.api.v2010.account.AddressCreator creator(String pathAccountSid, String customerName, String street, String city, String region, String postalCode, String isoCountry);
com.twilio.rest.api.v2010.account.AddressDeleter deleter(String pathAccountSid, String pathSid);
com.twilio.rest.api.v2010.account.AddressDeleter deleter(String pathSid);
com.twilio.rest.api.v2010.account.AddressFetcher fetcher(String pathAccountSid, String pathSid);
com.twilio.rest.api.v2010.account.AddressFetcher fetcher(String pathSid);
com.twilio.rest.api.v2010.account.AddressReader reader();
com.twilio.rest.api.v2010.account.AddressReader reader(String pathAccountSid);
com.twilio.rest.api.v2010.account.AddressUpdater updater(String pathAccountSid, String pathSid);
com.twilio.rest.api.v2010.account.AddressUpdater updater(String pathSid);
The address API is defined in the syntax as follows:
twilio:address/methodName?[parameters]
The 5 method(s) is listed in the table below. (API methods can have a shorthand alias name which can be used in the syntax instead of the name)
Method | Alias | Description |
---|---|---|
creator |
create |
Create a AddressCreator to execute create |
deleter |
delete |
Create a AddressDeleter to execute delete |
fetcher |
fetch |
Create a AddressFetcher to execute fetch |
reader |
read |
Create a AddressReader to execute read |
updater |
update |
Create a AddressUpdater to execute update |
The address API method(s) has the following set of parameters listed in the table below:
Method | Parameter | Description | Type |
---|---|---|---|
creator |
city |
The city of the new address |
String |
creator |
customerName |
The name to associate with the new address |
String |
creator |
isoCountry |
The ISO country code of the new address |
String |
creator |
pathAccountSid |
The SID of the Account that will be responsible for the new Address resource |
String |
creator |
postalCode |
The postal code of the new address |
String |
creator |
region |
The state or region of the new address |
String |
creator |
street |
The number and street address of the new address |
String |
deleter |
pathAccountSid |
The SID of the Account that is responsible for the resources to delete |
String |
deleter |
pathSid |
The unique string that identifies the resource |
String |
fetcher |
pathAccountSid |
The SID of the Account that is responsible for this address |
String |
fetcher |
pathSid |
The unique string that identifies the resource |
String |
reader |
pathAccountSid |
The SID of the Account that is responsible for this address |
String |
updater |
pathAccountSid |
The SID of the Account that is responsible for the resource to update |
String |
updater |
pathSid |
The unique string that identifies the resource |
String |
In addition to the parameters above, the address API can also use from the 21 endpoint query option which is listed in the Query Parameters section.
Any of the parameters can be provided in either the endpoint URI, or dynamically in a message header.
The message header name must be of the format CamelTwilio.parameter
.
The inBody
parameter overrides message header, i.e. the endpoint parameter inBody=myParameterNameHere
would override a CamelTwilio.myParameterNameHere
header.
API: address-dependent-phone-number
Both producer and consumer are supported
The address-dependent-phone-number API has 1 method(s) which is represented by the following method signatures (an API method may have multiple signatures due to overloading):
com.twilio.rest.api.v2010.account.address.DependentPhoneNumberReader reader(String pathAccountSid, String pathAddressSid);
com.twilio.rest.api.v2010.account.address.DependentPhoneNumberReader reader(String pathAddressSid);
The address-dependent-phone-number API is defined in the syntax as follows:
twilio:address-dependent-phone-number/methodName?[parameters]
The 1 method(s) is listed in the table below. (API methods can have a shorthand alias name which can be used in the syntax instead of the name)
Method | Alias | Description |
---|---|---|
reader |
read |
Create a DependentPhoneNumberReader to execute read |
The address-dependent-phone-number API method(s) has the following set of parameters listed in the table below:
Method | Parameter | Description | Type |
---|---|---|---|
reader |
pathAccountSid |
The SID of the Account that created the resources to read |
String |
reader |
pathAddressSid |
The SID of the Address resource associated with the phone number |
String |
In addition to the parameters above, the address-dependent-phone-number API can also use from the 21 endpoint query option which is listed in the Query Parameters section.
Any of the parameters can be provided in either the endpoint URI, or dynamically in a message header.
The message header name must be of the format CamelTwilio.parameter
.
The inBody
parameter overrides message header, i.e. the endpoint parameter inBody=myParameterNameHere
would override a CamelTwilio.myParameterNameHere
header.
API: application
Both producer and consumer are supported
The application API has 5 method(s) which is represented by the following method signatures (an API method may have multiple signatures due to overloading):
com.twilio.rest.api.v2010.account.ApplicationCreator creator();
com.twilio.rest.api.v2010.account.ApplicationCreator creator(String pathAccountSid);
com.twilio.rest.api.v2010.account.ApplicationDeleter deleter(String pathAccountSid, String pathSid);
com.twilio.rest.api.v2010.account.ApplicationDeleter deleter(String pathSid);
com.twilio.rest.api.v2010.account.ApplicationFetcher fetcher(String pathAccountSid, String pathSid);
com.twilio.rest.api.v2010.account.ApplicationFetcher fetcher(String pathSid);
com.twilio.rest.api.v2010.account.ApplicationReader reader();
com.twilio.rest.api.v2010.account.ApplicationReader reader(String pathAccountSid);
com.twilio.rest.api.v2010.account.ApplicationUpdater updater(String pathAccountSid, String pathSid);
com.twilio.rest.api.v2010.account.ApplicationUpdater updater(String pathSid);
The application API is defined in the syntax as follows:
twilio:application/methodName?[parameters]
The 5 method(s) is listed in the table below. (API methods can have a shorthand alias name which can be used in the syntax instead of the name)
Method | Alias | Description |
---|---|---|
creator |
create |
Create a ApplicationCreator to execute create |
deleter |
delete |
Create a ApplicationDeleter to execute delete |
fetcher |
fetch |
Create a ApplicationFetcher to execute fetch |
reader |
read |
Create a ApplicationReader to execute read |
updater |
update |
Create a ApplicationUpdater to execute update |
The application API method(s) has the following set of parameters listed in the table below:
Method | Parameter | Description | Type |
---|---|---|---|
creator |
pathAccountSid |
The SID of the Account that will create the resource |
String |
deleter |
pathAccountSid |
The SID of the Account that created the resources to delete |
String |
deleter |
pathSid |
The unique string that identifies the resource |
String |
fetcher |
pathAccountSid |
The SID of the Account that created the resource to fetch |
String |
fetcher |
pathSid |
The unique string that identifies the resource |
String |
reader |
pathAccountSid |
The SID of the Account that created the resources to read |
String |
updater |
pathAccountSid |
The SID of the Account that will create the resource |
String |
updater |
pathSid |
The unique string that identifies the resource |
String |
In addition to the parameters above, the application API can also use from the 21 endpoint query option which is listed in the Query Parameters section.
Any of the parameters can be provided in either the endpoint URI, or dynamically in a message header.
The message header name must be of the format CamelTwilio.parameter
.
The inBody
parameter overrides message header, i.e. the endpoint parameter inBody=myParameterNameHere
would override a CamelTwilio.myParameterNameHere
header.
API: available-phone-number-country
Both producer and consumer are supported
The available-phone-number-country API has 2 method(s) which is represented by the following method signatures (an API method may have multiple signatures due to overloading):
com.twilio.rest.api.v2010.account.AvailablePhoneNumberCountryFetcher fetcher(String pathAccountSid, String pathCountryCode);
com.twilio.rest.api.v2010.account.AvailablePhoneNumberCountryFetcher fetcher(String pathCountryCode);
com.twilio.rest.api.v2010.account.AvailablePhoneNumberCountryReader reader();
com.twilio.rest.api.v2010.account.AvailablePhoneNumberCountryReader reader(String pathAccountSid);
The available-phone-number-country API is defined in the syntax as follows:
twilio:available-phone-number-country/methodName?[parameters]
The 2 method(s) is listed in the table below. (API methods can have a shorthand alias name which can be used in the syntax instead of the name)
Method | Alias | Description |
---|---|---|
fetcher |
fetch |
Create a AvailablePhoneNumberCountryFetcher to execute fetch |
reader |
read |
Create a AvailablePhoneNumberCountryReader to execute read |
The available-phone-number-country API method(s) has the following set of parameters listed in the table below:
Method | Parameter | Description | Type |
---|---|---|---|
fetcher |
pathAccountSid |
The SID of the Account requesting the available phone number Country resource |
String |
fetcher |
pathCountryCode |
The ISO country code of the country to fetch available phone number information about |
String |
reader |
pathAccountSid |
The SID of the Account requesting the available phone number Country resources |
String |
In addition to the parameters above, the available-phone-number-country API can also use from the 21 endpoint query option which is listed in the Query Parameters section.
Any of the parameters can be provided in either the endpoint URI, or dynamically in a message header.
The message header name must be of the format CamelTwilio.parameter
.
The inBody
parameter overrides message header, i.e. the endpoint parameter inBody=myParameterNameHere
would override a CamelTwilio.myParameterNameHere
header.
API: available-phone-number-country-local
Both producer and consumer are supported
The available-phone-number-country-local API has 1 method(s) which is represented by the following method signatures (an API method may have multiple signatures due to overloading):
com.twilio.rest.api.v2010.account.availablephonenumbercountry.LocalReader reader(String pathAccountSid, String pathCountryCode);
com.twilio.rest.api.v2010.account.availablephonenumbercountry.LocalReader reader(String pathCountryCode);
The available-phone-number-country-local API is defined in the syntax as follows:
twilio:available-phone-number-country-local/methodName?[parameters]
The 1 method(s) is listed in the table below. (API methods can have a shorthand alias name which can be used in the syntax instead of the name)
Method | Alias | Description |
---|---|---|
reader |
read |
Create a LocalReader to execute read |
The available-phone-number-country-local API method(s) has the following set of parameters listed in the table below:
Method | Parameter | Description | Type |
---|---|---|---|
reader |
pathAccountSid |
The SID of the Account requesting the AvailablePhoneNumber resources |
String |
reader |
pathCountryCode |
The ISO Country code of the country from which to read phone numbers |
String |
In addition to the parameters above, the available-phone-number-country-local API can also use from the 21 endpoint query option which is listed in the Query Parameters section.
Any of the parameters can be provided in either the endpoint URI, or dynamically in a message header.
The message header name must be of the format CamelTwilio.parameter
.
The inBody
parameter overrides message header, i.e. the endpoint parameter inBody=myParameterNameHere
would override a CamelTwilio.myParameterNameHere
header.
API: available-phone-number-country-mobile
Both producer and consumer are supported
The available-phone-number-country-mobile API has 1 method(s) which is represented by the following method signatures (an API method may have multiple signatures due to overloading):
com.twilio.rest.api.v2010.account.availablephonenumbercountry.MobileReader reader(String pathAccountSid, String pathCountryCode);
com.twilio.rest.api.v2010.account.availablephonenumbercountry.MobileReader reader(String pathCountryCode);
The available-phone-number-country-mobile API is defined in the syntax as follows:
twilio:available-phone-number-country-mobile/methodName?[parameters]
The 1 method(s) is listed in the table below. (API methods can have a shorthand alias name which can be used in the syntax instead of the name)
Method | Alias | Description |
---|---|---|
reader |
read |
Create a MobileReader to execute read |
The available-phone-number-country-mobile API method(s) has the following set of parameters listed in the table below:
Method | Parameter | Description | Type |
---|---|---|---|
reader |
pathAccountSid |
The SID of the Account requesting the AvailablePhoneNumber resources |
String |
reader |
pathCountryCode |
The ISO Country code of the country from which to read phone numbers |
String |
In addition to the parameters above, the available-phone-number-country-mobile API can also use from the 21 endpoint query option which is listed in the Query Parameters section.
Any of the parameters can be provided in either the endpoint URI, or dynamically in a message header.
The message header name must be of the format CamelTwilio.parameter
.
The inBody
parameter overrides message header, i.e. the endpoint parameter inBody=myParameterNameHere
would override a CamelTwilio.myParameterNameHere
header.
API: available-phone-number-country-toll-free
Both producer and consumer are supported
The available-phone-number-country-toll-free API has 1 method(s) which is represented by the following method signatures (an API method may have multiple signatures due to overloading):
com.twilio.rest.api.v2010.account.availablephonenumbercountry.TollFreeReader reader(String pathAccountSid, String pathCountryCode);
com.twilio.rest.api.v2010.account.availablephonenumbercountry.TollFreeReader reader(String pathCountryCode);
The available-phone-number-country-toll-free API is defined in the syntax as follows:
twilio:available-phone-number-country-toll-free/methodName?[parameters]
The 1 method(s) is listed in the table below. (API methods can have a shorthand alias name which can be used in the syntax instead of the name)
Method | Alias | Description |
---|---|---|
reader |
read |
Create a TollFreeReader to execute read |
The available-phone-number-country-toll-free API method(s) has the following set of parameters listed in the table below:
Method | Parameter | Description | Type |
---|---|---|---|
reader |
pathAccountSid |
The SID of the Account requesting the AvailablePhoneNumber resources |
String |
reader |
pathCountryCode |
The ISO Country code of the country from which to read phone numbers |
String |
In addition to the parameters above, the available-phone-number-country-toll-free API can also use from the 21 endpoint query option which is listed in the Query Parameters section.
Any of the parameters can be provided in either the endpoint URI, or dynamically in a message header.
The message header name must be of the format CamelTwilio.parameter
.
The inBody
parameter overrides message header, i.e. the endpoint parameter inBody=myParameterNameHere
would override a CamelTwilio.myParameterNameHere
header.
API: call
Both producer and consumer are supported
The call API has 5 method(s) which is represented by the following method signatures (an API method may have multiple signatures due to overloading):
com.twilio.rest.api.v2010.account.CallCreator creator(String pathAccountSid, com.twilio.type.Endpoint to, com.twilio.type.Endpoint from, String applicationSid);
com.twilio.rest.api.v2010.account.CallCreator creator(String pathAccountSid, com.twilio.type.Endpoint to, com.twilio.type.Endpoint from, com.twilio.type.Twiml twiml);
com.twilio.rest.api.v2010.account.CallCreator creator(String pathAccountSid, com.twilio.type.Endpoint to, com.twilio.type.Endpoint from, java.net.URI url);
com.twilio.rest.api.v2010.account.CallCreator creator(com.twilio.type.Endpoint to, com.twilio.type.Endpoint from, String applicationSid);
com.twilio.rest.api.v2010.account.CallCreator creator(com.twilio.type.Endpoint to, com.twilio.type.Endpoint from, com.twilio.type.Twiml twiml);
com.twilio.rest.api.v2010.account.CallCreator creator(com.twilio.type.Endpoint to, com.twilio.type.Endpoint from, java.net.URI url);
com.twilio.rest.api.v2010.account.CallDeleter deleter(String pathAccountSid, String pathSid);
com.twilio.rest.api.v2010.account.CallDeleter deleter(String pathSid);
com.twilio.rest.api.v2010.account.CallFetcher fetcher(String pathAccountSid, String pathSid);
com.twilio.rest.api.v2010.account.CallFetcher fetcher(String pathSid);
com.twilio.rest.api.v2010.account.CallReader reader();
com.twilio.rest.api.v2010.account.CallReader reader(String pathAccountSid);
com.twilio.rest.api.v2010.account.CallUpdater updater(String pathAccountSid, String pathSid);
com.twilio.rest.api.v2010.account.CallUpdater updater(String pathSid);
The call API is defined in the syntax as follows:
twilio:call/methodName?[parameters]
The 5 method(s) is listed in the table below. (API methods can have a shorthand alias name which can be used in the syntax instead of the name)
Method | Alias | Description |
---|---|---|
creator |
create |
Create a CallCreator to execute create |
deleter |
delete |
Create a CallDeleter to execute delete |
fetcher |
fetch |
Create a CallFetcher to execute fetch |
reader |
read |
Create a CallReader to execute read |
updater |
update |
Create a CallUpdater to execute update |
The call API method(s) has the following set of parameters listed in the table below:
Method | Parameter | Description | Type |
---|---|---|---|
creator |
applicationSid |
The SID of the Application resource that will handle the call |
String |
creator |
from |
Twilio number from which to originate the call |
Endpoint |
creator |
pathAccountSid |
The SID of the Account that will create the resource |
String |
creator |
to |
Phone number, SIP address, or client identifier to call |
Endpoint |
creator |
twiml |
TwiML instructions for the call |
Twiml |
creator |
url |
The absolute URL that returns TwiML for this call |
URI |
deleter |
pathAccountSid |
The SID of the Account that created the resource(s) to delete |
String |
deleter |
pathSid |
The unique string that identifies this resource |
String |
fetcher |
pathAccountSid |
The SID of the Account that created the resource(s) to fetch |
String |
fetcher |
pathSid |
The SID of the Call resource to fetch |
String |
reader |
pathAccountSid |
The SID of the Account that created the resource(s) to read |
String |
updater |
pathAccountSid |
The SID of the Account that created the resource(s) to update |
String |
updater |
pathSid |
The unique string that identifies this resource |
String |
In addition to the parameters above, the call API can also use from the 21 endpoint query option which is listed in the Query Parameters section.
Any of the parameters can be provided in either the endpoint URI, or dynamically in a message header.
The message header name must be of the format CamelTwilio.parameter
.
The inBody
parameter overrides message header, i.e. the endpoint parameter inBody=myParameterNameHere
would override a CamelTwilio.myParameterNameHere
header.
API: call-feedback
Both producer and consumer are supported
The call-feedback API has 3 method(s) which is represented by the following method signatures (an API method may have multiple signatures due to overloading):
com.twilio.rest.api.v2010.account.call.FeedbackCreator creator(String pathAccountSid, String pathCallSid, Integer qualityScore);
com.twilio.rest.api.v2010.account.call.FeedbackCreator creator(String pathCallSid, Integer qualityScore);
com.twilio.rest.api.v2010.account.call.FeedbackFetcher fetcher(String pathAccountSid, String pathCallSid);
com.twilio.rest.api.v2010.account.call.FeedbackFetcher fetcher(String pathCallSid);
com.twilio.rest.api.v2010.account.call.FeedbackUpdater updater(String pathAccountSid, String pathCallSid, Integer qualityScore);
com.twilio.rest.api.v2010.account.call.FeedbackUpdater updater(String pathCallSid, Integer qualityScore);
The call-feedback API is defined in the syntax as follows:
twilio:call-feedback/methodName?[parameters]
The 3 method(s) is listed in the table below. (API methods can have a shorthand alias name which can be used in the syntax instead of the name)
Method | Alias | Description |
---|---|---|
creator |
create |
Create a FeedbackCreator to execute create |
fetcher |
fetch |
Create a FeedbackFetcher to execute fetch |
updater |
update |
Create a FeedbackUpdater to execute update |
The call-feedback API method(s) has the following set of parameters listed in the table below:
Method | Parameter | Description | Type |
---|---|---|---|
creator |
pathAccountSid |
The unique sid that identifies this account |
String |
creator |
pathCallSid |
The call sid that uniquely identifies the call |
String |
creator |
qualityScore |
The call quality expressed as an integer from 1 to 5 |
Integer |
fetcher |
pathAccountSid |
The unique sid that identifies this account |
String |
fetcher |
pathCallSid |
The call sid that uniquely identifies the call |
String |
updater |
pathAccountSid |
The unique sid that identifies this account |
String |
updater |
pathCallSid |
The call sid that uniquely identifies the call |
String |
updater |
qualityScore |
The call quality expressed as an integer from 1 to 5 |
Integer |
In addition to the parameters above, the call-feedback API can also use from the 21 endpoint query option which is listed in the Query Parameters section.
Any of the parameters can be provided in either the endpoint URI, or dynamically in a message header.
The message header name must be of the format CamelTwilio.parameter
.
The inBody
parameter overrides message header, i.e. the endpoint parameter inBody=myParameterNameHere
would override a CamelTwilio.myParameterNameHere
header.
API: call-feedback-summary
Both producer and consumer are supported
The call-feedback-summary API has 3 method(s) which is represented by the following method signatures (an API method may have multiple signatures due to overloading):
com.twilio.rest.api.v2010.account.call.FeedbackSummaryCreator creator(String pathAccountSid, org.joda.time.LocalDate startDate, org.joda.time.LocalDate endDate);
com.twilio.rest.api.v2010.account.call.FeedbackSummaryCreator creator(org.joda.time.LocalDate startDate, org.joda.time.LocalDate endDate);
com.twilio.rest.api.v2010.account.call.FeedbackSummaryDeleter deleter(String pathAccountSid, String pathSid);
com.twilio.rest.api.v2010.account.call.FeedbackSummaryDeleter deleter(String pathSid);
com.twilio.rest.api.v2010.account.call.FeedbackSummaryFetcher fetcher(String pathAccountSid, String pathSid);
com.twilio.rest.api.v2010.account.call.FeedbackSummaryFetcher fetcher(String pathSid);
The call-feedback-summary API is defined in the syntax as follows:
twilio:call-feedback-summary/methodName?[parameters]
The 3 method(s) is listed in the table below. (API methods can have a shorthand alias name which can be used in the syntax instead of the name)
Method | Alias | Description |
---|---|---|
creator |
create |
Create a FeedbackSummaryCreator to execute create |
deleter |
delete |
Create a FeedbackSummaryDeleter to execute delete |
fetcher |
fetch |
Create a FeedbackSummaryFetcher to execute fetch |
The call-feedback-summary API method(s) has the following set of parameters listed in the table below:
Method | Parameter | Description | Type |
---|---|---|---|
creator |
endDate |
Only include feedback given on or before this date |
LocalDate |
creator |
pathAccountSid |
The unique sid that identifies this account |
String |
creator |
startDate |
Only include feedback given on or after this date |
LocalDate |
deleter |
pathAccountSid |
The unique sid that identifies this account |
String |
deleter |
pathSid |
A string that uniquely identifies this feedback summary resource |
String |
fetcher |
pathAccountSid |
The unique sid that identifies this account |
String |
fetcher |
pathSid |
A string that uniquely identifies this feedback summary resource |
String |
In addition to the parameters above, the call-feedback-summary API can also use from the 21 endpoint query option which is listed in the Query Parameters section.
Any of the parameters can be provided in either the endpoint URI, or dynamically in a message header.
The message header name must be of the format CamelTwilio.parameter
.
The inBody
parameter overrides message header, i.e. the endpoint parameter inBody=myParameterNameHere
would override a CamelTwilio.myParameterNameHere
header.
API: call-notification
Both producer and consumer are supported
The call-notification API has 2 method(s) which is represented by the following method signatures (an API method may have multiple signatures due to overloading):
com.twilio.rest.api.v2010.account.call.NotificationFetcher fetcher(String pathAccountSid, String pathCallSid, String pathSid);
com.twilio.rest.api.v2010.account.call.NotificationFetcher fetcher(String pathCallSid, String pathSid);
com.twilio.rest.api.v2010.account.call.NotificationReader reader(String pathAccountSid, String pathCallSid);
com.twilio.rest.api.v2010.account.call.NotificationReader reader(String pathCallSid);
The call-notification API is defined in the syntax as follows:
twilio:call-notification/methodName?[parameters]
The 2 method(s) is listed in the table below. (API methods can have a shorthand alias name which can be used in the syntax instead of the name)
Method | Alias | Description |
---|---|---|
fetcher |
fetch |
Create a NotificationFetcher to execute fetch |
reader |
read |
Create a NotificationReader to execute read |
The call-notification API method(s) has the following set of parameters listed in the table below:
Method | Parameter | Description | Type |
---|---|---|---|
fetcher |
pathAccountSid |
The SID of the Account that created the resource to fetch |
String |
fetcher |
pathCallSid |
The Call SID of the resource to fetch |
String |
fetcher |
pathSid |
The unique string that identifies the resource |
String |
reader |
pathAccountSid |
The SID of the Account that created the resources to read |
String |
reader |
pathCallSid |
The Call SID of the resource to fetch |
String |
In addition to the parameters above, the call-notification API can also use from the 21 endpoint query option which is listed in the Query Parameters section.
Any of the parameters can be provided in either the endpoint URI, or dynamically in a message header.
The message header name must be of the format CamelTwilio.parameter
.
The inBody
parameter overrides message header, i.e. the endpoint parameter inBody=myParameterNameHere
would override a CamelTwilio.myParameterNameHere
header.
API: call-recording
Both producer and consumer are supported
The call-recording API has 5 method(s) which is represented by the following method signatures (an API method may have multiple signatures due to overloading):
com.twilio.rest.api.v2010.account.call.RecordingCreator creator(String pathAccountSid, String pathCallSid);
com.twilio.rest.api.v2010.account.call.RecordingCreator creator(String pathCallSid);
com.twilio.rest.api.v2010.account.call.RecordingDeleter deleter(String pathAccountSid, String pathCallSid, String pathSid);
com.twilio.rest.api.v2010.account.call.RecordingDeleter deleter(String pathCallSid, String pathSid);
com.twilio.rest.api.v2010.account.call.RecordingFetcher fetcher(String pathAccountSid, String pathCallSid, String pathSid);
com.twilio.rest.api.v2010.account.call.RecordingFetcher fetcher(String pathCallSid, String pathSid);
com.twilio.rest.api.v2010.account.call.RecordingReader reader(String pathAccountSid, String pathCallSid);
com.twilio.rest.api.v2010.account.call.RecordingReader reader(String pathCallSid);
com.twilio.rest.api.v2010.account.call.RecordingUpdater updater(String pathAccountSid, String pathCallSid, String pathSid, com.twilio.rest.api.v2010.account.call.Recording.Status status);
com.twilio.rest.api.v2010.account.call.RecordingUpdater updater(String pathCallSid, String pathSid, com.twilio.rest.api.v2010.account.call.Recording.Status status);
The call-recording API is defined in the syntax as follows:
twilio:call-recording/methodName?[parameters]
The 5 method(s) is listed in the table below. (API methods can have a shorthand alias name which can be used in the syntax instead of the name)
Method | Alias | Description |
---|---|---|
creator |
create |
Create a RecordingCreator to execute create |
deleter |
delete |
Create a RecordingDeleter to execute delete |
fetcher |
fetch |
Create a RecordingFetcher to execute fetch |
reader |
read |
Create a RecordingReader to execute read |
updater |
update |
Create a RecordingUpdater to execute update |
The call-recording API method(s) has the following set of parameters listed in the table below:
Method | Parameter | Description | Type |
---|---|---|---|
creator |
pathAccountSid |
The SID of the Account that will create the resource |
String |
creator |
pathCallSid |
The SID of the Call to associate the resource with |
String |
deleter |
pathAccountSid |
The SID of the Account that created the resources to delete |
String |
deleter |
pathCallSid |
The SID of the Call to associate the resource with |
String |
deleter |
pathSid |
The unique string that identifies the resource |
String |
fetcher |
pathAccountSid |
The SID of the Account that created the resource to fetch |
String |
fetcher |
pathCallSid |
The SID of the Call to associate the resource with |
String |
fetcher |
pathSid |
The unique string that identifies the resource |
String |
reader |
pathAccountSid |
The SID of the Account that created the resources to read |
String |
reader |
pathCallSid |
The SID of the Call to associate the resource with |
String |
updater |
pathAccountSid |
The SID of the Account that created the resource to update |
String |
updater |
pathCallSid |
The SID of the Call to associate the resource with |
String |
updater |
pathSid |
The unique string that identifies the resource |
String |
updater |
status |
The new status of the recording |
Status |
In addition to the parameters above, the call-recording API can also use from the 21 endpoint query option which is listed in the Query Parameters section.
Any of the parameters can be provided in either the endpoint URI, or dynamically in a message header.
The message header name must be of the format CamelTwilio.parameter
.
The inBody
parameter overrides message header, i.e. the endpoint parameter inBody=myParameterNameHere
would override a CamelTwilio.myParameterNameHere
header.
API: conference
Both producer and consumer are supported
The conference API has 3 method(s) which is represented by the following method signatures (an API method may have multiple signatures due to overloading):
com.twilio.rest.api.v2010.account.ConferenceFetcher fetcher(String pathAccountSid, String pathSid);
com.twilio.rest.api.v2010.account.ConferenceFetcher fetcher(String pathSid);
com.twilio.rest.api.v2010.account.ConferenceReader reader();
com.twilio.rest.api.v2010.account.ConferenceReader reader(String pathAccountSid);
com.twilio.rest.api.v2010.account.ConferenceUpdater updater(String pathAccountSid, String pathSid);
com.twilio.rest.api.v2010.account.ConferenceUpdater updater(String pathSid);
The conference API is defined in the syntax as follows:
twilio:conference/methodName?[parameters]
The 3 method(s) is listed in the table below. (API methods can have a shorthand alias name which can be used in the syntax instead of the name)
Method | Alias | Description |
---|---|---|
fetcher |
fetch |
Create a ConferenceFetcher to execute fetch |
reader |
read |
Create a ConferenceReader to execute read |
updater |
update |
Create a ConferenceUpdater to execute update |
The conference API method(s) has the following set of parameters listed in the table below:
Method | Parameter | Description | Type |
---|---|---|---|
fetcher |
pathAccountSid |
The SID of the Account that created the resource(s) to fetch |
String |
fetcher |
pathSid |
The unique string that identifies this resource |
String |
reader |
pathAccountSid |
The SID of the Account that created the resource(s) to read |
String |
updater |
pathAccountSid |
The SID of the Account that created the resource(s) to update |
String |
updater |
pathSid |
The unique string that identifies this resource |
String |
In addition to the parameters above, the conference API can also use from the 21 endpoint query option which is listed in the Query Parameters section.
Any of the parameters can be provided in either the endpoint URI, or dynamically in a message header.
The message header name must be of the format CamelTwilio.parameter
.
The inBody
parameter overrides message header, i.e. the endpoint parameter inBody=myParameterNameHere
would override a CamelTwilio.myParameterNameHere
header.
API: conference-participant
Both producer and consumer are supported
The conference-participant API has 5 method(s) which is represented by the following method signatures (an API method may have multiple signatures due to overloading):
com.twilio.rest.api.v2010.account.conference.ParticipantCreator creator(String pathAccountSid, String pathConferenceSid, com.twilio.type.PhoneNumber from, com.twilio.type.PhoneNumber to);
com.twilio.rest.api.v2010.account.conference.ParticipantCreator creator(String pathConferenceSid, com.twilio.type.PhoneNumber from, com.twilio.type.PhoneNumber to);
com.twilio.rest.api.v2010.account.conference.ParticipantDeleter deleter(String pathAccountSid, String pathConferenceSid, String pathCallSid);
com.twilio.rest.api.v2010.account.conference.ParticipantDeleter deleter(String pathConferenceSid, String pathCallSid);
com.twilio.rest.api.v2010.account.conference.ParticipantFetcher fetcher(String pathAccountSid, String pathConferenceSid, String pathCallSid);
com.twilio.rest.api.v2010.account.conference.ParticipantFetcher fetcher(String pathConferenceSid, String pathCallSid);
com.twilio.rest.api.v2010.account.conference.ParticipantReader reader(String pathAccountSid, String pathConferenceSid);
com.twilio.rest.api.v2010.account.conference.ParticipantReader reader(String pathConferenceSid);
com.twilio.rest.api.v2010.account.conference.ParticipantUpdater updater(String pathAccountSid, String pathConferenceSid, String pathCallSid);
com.twilio.rest.api.v2010.account.conference.ParticipantUpdater updater(String pathConferenceSid, String pathCallSid);
The conference-participant API is defined in the syntax as follows:
twilio:conference-participant/methodName?[parameters]
The 5 method(s) is listed in the table below. (API methods can have a shorthand alias name which can be used in the syntax instead of the name)
Method | Alias | Description |
---|---|---|
creator |
create |
Create a ParticipantCreator to execute create |
deleter |
delete |
Create a ParticipantDeleter to execute delete |
fetcher |
fetch |
Create a ParticipantFetcher to execute fetch |
reader |
read |
Create a ParticipantReader to execute read |
updater |
update |
Create a ParticipantUpdater to execute update |
The conference-participant API method(s) has the following set of parameters listed in the table below:
Method | Parameter | Description | Type |
---|---|---|---|
creator |
from |
The phone number, Client identifier, or username portion of SIP address that made this call. |
PhoneNumber |
creator |
pathAccountSid |
The SID of the Account that will create the resource |
String |
creator |
pathConferenceSid |
The SID of the participant’s conference |
String |
creator |
to |
The phone number, SIP address or Client identifier that received this call. |
PhoneNumber |
deleter |
pathAccountSid |
The SID of the Account that created the resources to delete |
String |
deleter |
pathCallSid |
The Call SID or URL encoded label of the participant to delete |
String |
deleter |
pathConferenceSid |
The SID of the participant’s conference |
String |
fetcher |
pathAccountSid |
The SID of the Account that created the resource to fetch |
String |
fetcher |
pathCallSid |
The Call SID or URL encoded label of the participant to fetch |
String |
fetcher |
pathConferenceSid |
The SID of the participant’s conference |
String |
reader |
pathAccountSid |
The SID of the Account that created the resources to read |
String |
reader |
pathConferenceSid |
The SID of the participant’s conference |
String |
updater |
pathAccountSid |
The SID of the Account that created the resources to update |
String |
updater |
pathCallSid |
The Call SID or URL encoded label of the participant to update |
String |
updater |
pathConferenceSid |
The SID of the participant’s conference |
String |
In addition to the parameters above, the conference-participant API can also use from the 21 endpoint query option which is listed in the Query Parameters section.
Any of the parameters can be provided in either the endpoint URI, or dynamically in a message header.
The message header name must be of the format CamelTwilio.parameter
.
The inBody
parameter overrides message header, i.e. the endpoint parameter inBody=myParameterNameHere
would override a CamelTwilio.myParameterNameHere
header.
API: connect-app
Both producer and consumer are supported
The connect-app API has 4 method(s) which is represented by the following method signatures (an API method may have multiple signatures due to overloading):
com.twilio.rest.api.v2010.account.ConnectAppDeleter deleter(String pathAccountSid, String pathSid);
com.twilio.rest.api.v2010.account.ConnectAppDeleter deleter(String pathSid);
com.twilio.rest.api.v2010.account.ConnectAppFetcher fetcher(String pathAccountSid, String pathSid);
com.twilio.rest.api.v2010.account.ConnectAppFetcher fetcher(String pathSid);
com.twilio.rest.api.v2010.account.ConnectAppReader reader();
com.twilio.rest.api.v2010.account.ConnectAppReader reader(String pathAccountSid);
com.twilio.rest.api.v2010.account.ConnectAppUpdater updater(String pathAccountSid, String pathSid);
com.twilio.rest.api.v2010.account.ConnectAppUpdater updater(String pathSid);
The connect-app API is defined in the syntax as follows:
twilio:connect-app/methodName?[parameters]
The 4 method(s) is listed in the table below. (API methods can have a shorthand alias name which can be used in the syntax instead of the name)
Method | Alias | Description |
---|---|---|
deleter |
delete |
Create a ConnectAppDeleter to execute delete |
fetcher |
fetch |
Create a ConnectAppFetcher to execute fetch |
reader |
read |
Create a ConnectAppReader to execute read |
updater |
update |
Create a ConnectAppUpdater to execute update |
The connect-app API method(s) has the following set of parameters listed in the table below:
Method | Parameter | Description | Type |
---|---|---|---|
deleter |
pathAccountSid |
The SID of the Account that created the resource to fetch |
String |
deleter |
pathSid |
The unique string that identifies the resource |
String |
fetcher |
pathAccountSid |
The SID of the Account that created the resource to fetch |
String |
fetcher |
pathSid |
The unique string that identifies the resource |
String |
reader |
pathAccountSid |
The SID of the Account that created the resources to read |
String |
updater |
pathAccountSid |
The SID of the Account that created the resources to update |
String |
updater |
pathSid |
The unique string that identifies the resource |
String |
In addition to the parameters above, the connect-app API can also use from the 21 endpoint query option which is listed in the Query Parameters section.
Any of the parameters can be provided in either the endpoint URI, or dynamically in a message header.
The message header name must be of the format CamelTwilio.parameter
.
The inBody
parameter overrides message header, i.e. the endpoint parameter inBody=myParameterNameHere
would override a CamelTwilio.myParameterNameHere
header.
API: incoming-phone-number
Both producer and consumer are supported
The incoming-phone-number API has 5 method(s) which is represented by the following method signatures (an API method may have multiple signatures due to overloading):
com.twilio.rest.api.v2010.account.IncomingPhoneNumberCreator creator(String areaCode);
com.twilio.rest.api.v2010.account.IncomingPhoneNumberCreator creator(String pathAccountSid, String areaCode);
com.twilio.rest.api.v2010.account.IncomingPhoneNumberCreator creator(String pathAccountSid, com.twilio.type.PhoneNumber phoneNumber);
com.twilio.rest.api.v2010.account.IncomingPhoneNumberCreator creator(com.twilio.type.PhoneNumber phoneNumber);
com.twilio.rest.api.v2010.account.IncomingPhoneNumberDeleter deleter(String pathAccountSid, String pathSid);
com.twilio.rest.api.v2010.account.IncomingPhoneNumberDeleter deleter(String pathSid);
com.twilio.rest.api.v2010.account.IncomingPhoneNumberFetcher fetcher(String pathAccountSid, String pathSid);
com.twilio.rest.api.v2010.account.IncomingPhoneNumberFetcher fetcher(String pathSid);
com.twilio.rest.api.v2010.account.IncomingPhoneNumberReader reader();
com.twilio.rest.api.v2010.account.IncomingPhoneNumberReader reader(String pathAccountSid);
com.twilio.rest.api.v2010.account.IncomingPhoneNumberUpdater updater(String pathAccountSid, String pathSid);
com.twilio.rest.api.v2010.account.IncomingPhoneNumberUpdater updater(String pathSid);
The incoming-phone-number API is defined in the syntax as follows:
twilio:incoming-phone-number/methodName?[parameters]
The 5 method(s) is listed in the table below. (API methods can have a shorthand alias name which can be used in the syntax instead of the name)
Method | Alias | Description |
---|---|---|
creator |
create |
Create a IncomingPhoneNumberCreator to execute create |
deleter |
delete |
Create a IncomingPhoneNumberDeleter to execute delete |
fetcher |
fetch |
Create a IncomingPhoneNumberFetcher to execute fetch |
reader |
read |
Create a IncomingPhoneNumberReader to execute read |
updater |
update |
Create a IncomingPhoneNumberUpdater to execute update |
The incoming-phone-number API method(s) has the following set of parameters listed in the table below:
Method | Parameter | Description | Type |
---|---|---|---|
creator |
areaCode |
The desired area code for the new phone number |
String |
creator |
pathAccountSid |
The SID of the Account that will create the resource |
String |
creator |
phoneNumber |
The phone number to purchase in E.164 format |
PhoneNumber |
deleter |
pathAccountSid |
The SID of the Account that created the resources to delete |
String |
deleter |
pathSid |
The unique string that identifies the resource |
String |
fetcher |
pathAccountSid |
The SID of the Account that created the resource to fetch |
String |
fetcher |
pathSid |
The unique string that identifies the resource |
String |
reader |
pathAccountSid |
The SID of the Account that created the resources to read |
String |
updater |
pathAccountSid |
The SID of the Account that created the resource to update |
String |
updater |
pathSid |
The unique string that identifies the resource |
String |
In addition to the parameters above, the incoming-phone-number API can also use from the 21 endpoint query option which is listed in the Query Parameters section.
Any of the parameters can be provided in either the endpoint URI, or dynamically in a message header.
The message header name must be of the format CamelTwilio.parameter
.
The inBody
parameter overrides message header, i.e. the endpoint parameter inBody=myParameterNameHere
would override a CamelTwilio.myParameterNameHere
header.
API: incoming-phone-number-local
Both producer and consumer are supported
The incoming-phone-number-local API has 2 method(s) which is represented by the following method signatures (an API method may have multiple signatures due to overloading):
com.twilio.rest.api.v2010.account.incomingphonenumber.LocalCreator creator(String pathAccountSid, com.twilio.type.PhoneNumber phoneNumber);
com.twilio.rest.api.v2010.account.incomingphonenumber.LocalCreator creator(com.twilio.type.PhoneNumber phoneNumber);
com.twilio.rest.api.v2010.account.incomingphonenumber.LocalReader reader();
com.twilio.rest.api.v2010.account.incomingphonenumber.LocalReader reader(String pathAccountSid);
The incoming-phone-number-local API is defined in the syntax as follows:
twilio:incoming-phone-number-local/methodName?[parameters]
The 2 method(s) is listed in the table below. (API methods can have a shorthand alias name which can be used in the syntax instead of the name)
Method | Alias | Description |
---|---|---|
creator |
create |
Create a LocalCreator to execute create |
reader |
read |
Create a LocalReader to execute read |
The incoming-phone-number-local API method(s) has the following set of parameters listed in the table below:
Method | Parameter | Description | Type |
---|---|---|---|
creator |
pathAccountSid |
The SID of the Account that will create the resource |
String |
creator |
phoneNumber |
The phone number to purchase in E.164 format |
PhoneNumber |
reader |
pathAccountSid |
The SID of the Account that created the resources to read |
String |
In addition to the parameters above, the incoming-phone-number-local API can also use from the 21 endpoint query option which is listed in the Query Parameters section.
Any of the parameters can be provided in either the endpoint URI, or dynamically in a message header.
The message header name must be of the format CamelTwilio.parameter
.
The inBody
parameter overrides message header, i.e. the endpoint parameter inBody=myParameterNameHere
would override a CamelTwilio.myParameterNameHere
header.
API: incoming-phone-number-mobile
Both producer and consumer are supported
The incoming-phone-number-mobile API has 2 method(s) which is represented by the following method signatures (an API method may have multiple signatures due to overloading):
com.twilio.rest.api.v2010.account.incomingphonenumber.MobileCreator creator(String pathAccountSid, com.twilio.type.PhoneNumber phoneNumber);
com.twilio.rest.api.v2010.account.incomingphonenumber.MobileCreator creator(com.twilio.type.PhoneNumber phoneNumber);
com.twilio.rest.api.v2010.account.incomingphonenumber.MobileReader reader();
com.twilio.rest.api.v2010.account.incomingphonenumber.MobileReader reader(String pathAccountSid);
The incoming-phone-number-mobile API is defined in the syntax as follows:
twilio:incoming-phone-number-mobile/methodName?[parameters]
The 2 method(s) is listed in the table below. (API methods can have a shorthand alias name which can be used in the syntax instead of the name)
Method | Alias | Description |
---|---|---|
creator |
create |
Create a MobileCreator to execute create |
reader |
read |
Create a MobileReader to execute read |
The incoming-phone-number-mobile API method(s) has the following set of parameters listed in the table below:
Method | Parameter | Description | Type |
---|---|---|---|
creator |
pathAccountSid |
The SID of the Account that will create the resource |
String |
creator |
phoneNumber |
The phone number to purchase in E.164 format |
PhoneNumber |
reader |
pathAccountSid |
The SID of the Account that created the resources to read |
String |
In addition to the parameters above, the incoming-phone-number-mobile API can also use from the 21 endpoint query option which is listed in the Query Parameters section.
Any of the parameters can be provided in either the endpoint URI, or dynamically in a message header.
The message header name must be of the format CamelTwilio.parameter
.
The inBody
parameter overrides message header, i.e. the endpoint parameter inBody=myParameterNameHere
would override a CamelTwilio.myParameterNameHere
header.
API: incoming-phone-number-toll-free
Both producer and consumer are supported
The incoming-phone-number-toll-free API has 2 method(s) which is represented by the following method signatures (an API method may have multiple signatures due to overloading):
com.twilio.rest.api.v2010.account.incomingphonenumber.TollFreeCreator creator(String pathAccountSid, com.twilio.type.PhoneNumber phoneNumber);
com.twilio.rest.api.v2010.account.incomingphonenumber.TollFreeCreator creator(com.twilio.type.PhoneNumber phoneNumber);
com.twilio.rest.api.v2010.account.incomingphonenumber.TollFreeReader reader();
com.twilio.rest.api.v2010.account.incomingphonenumber.TollFreeReader reader(String pathAccountSid);
The incoming-phone-number-toll-free API is defined in the syntax as follows:
twilio:incoming-phone-number-toll-free/methodName?[parameters]
The 2 method(s) is listed in the table below. (API methods can have a shorthand alias name which can be used in the syntax instead of the name)
Method | Alias | Description |
---|---|---|
creator |
create |
Create a TollFreeCreator to execute create |
reader |
read |
Create a TollFreeReader to execute read |
The incoming-phone-number-toll-free API method(s) has the following set of parameters listed in the table below:
Method | Parameter | Description | Type |
---|---|---|---|
creator |
pathAccountSid |
The SID of the Account that will create the resource |
String |
creator |
phoneNumber |
The phone number to purchase in E.164 format |
PhoneNumber |
reader |
pathAccountSid |
The SID of the Account that created the resources to read |
String |
In addition to the parameters above, the incoming-phone-number-toll-free API can also use from the 21 endpoint query option which is listed in the Query Parameters section.
Any of the parameters can be provided in either the endpoint URI, or dynamically in a message header.
The message header name must be of the format CamelTwilio.parameter
.
The inBody
parameter overrides message header, i.e. the endpoint parameter inBody=myParameterNameHere
would override a CamelTwilio.myParameterNameHere
header.
API: key
Both producer and consumer are supported
The key API has 4 method(s) which is represented by the following method signatures (an API method may have multiple signatures due to overloading):
com.twilio.rest.api.v2010.account.KeyDeleter deleter(String pathAccountSid, String pathSid);
com.twilio.rest.api.v2010.account.KeyDeleter deleter(String pathSid);
com.twilio.rest.api.v2010.account.KeyFetcher fetcher(String pathAccountSid, String pathSid);
com.twilio.rest.api.v2010.account.KeyFetcher fetcher(String pathSid);
com.twilio.rest.api.v2010.account.KeyReader reader();
com.twilio.rest.api.v2010.account.KeyReader reader(String pathAccountSid);
com.twilio.rest.api.v2010.account.KeyUpdater updater(String pathAccountSid, String pathSid);
com.twilio.rest.api.v2010.account.KeyUpdater updater(String pathSid);
The key API is defined in the syntax as follows:
twilio:key/methodName?[parameters]
The 4 method(s) is listed in the table below. (API methods can have a shorthand alias name which can be used in the syntax instead of the name)
Method | Alias | Description |
---|---|---|
deleter |
delete |
Create a KeyDeleter to execute delete |
fetcher |
fetch |
Create a KeyFetcher to execute fetch |
reader |
read |
Create a KeyReader to execute read |
updater |
update |
Create a KeyUpdater to execute update |
The key API method(s) has the following set of parameters listed in the table below:
Method | Parameter | Description | Type |
---|---|---|---|
deleter |
pathAccountSid |
The SID of the Account that created the resources to delete |
String |
deleter |
pathSid |
The unique string that identifies the resource |
String |
fetcher |
pathAccountSid |
The SID of the Account that created the resource to fetch |
String |
fetcher |
pathSid |
The unique string that identifies the resource |
String |
reader |
pathAccountSid |
The SID of the Account that created the resources to read |
String |
updater |
pathAccountSid |
The SID of the Account that created the resources to update |
String |
updater |
pathSid |
The unique string that identifies the resource |
String |
In addition to the parameters above, the key API can also use from the 21 endpoint query option which is listed in the Query Parameters section.
Any of the parameters can be provided in either the endpoint URI, or dynamically in a message header.
The message header name must be of the format CamelTwilio.parameter
.
The inBody
parameter overrides message header, i.e. the endpoint parameter inBody=myParameterNameHere
would override a CamelTwilio.myParameterNameHere
header.
API: message
Both producer and consumer are supported
The message API has 5 method(s) which is represented by the following method signatures (an API method may have multiple signatures due to overloading):
com.twilio.rest.api.v2010.account.MessageCreator creator(String pathAccountSid, com.twilio.type.PhoneNumber to, String messagingServiceSid, String body);
com.twilio.rest.api.v2010.account.MessageCreator creator(String pathAccountSid, com.twilio.type.PhoneNumber to, String messagingServiceSid, java.util.List<java.net.URI> mediaUrl);
com.twilio.rest.api.v2010.account.MessageCreator creator(String pathAccountSid, com.twilio.type.PhoneNumber to, com.twilio.type.PhoneNumber from, String body);
com.twilio.rest.api.v2010.account.MessageCreator creator(String pathAccountSid, com.twilio.type.PhoneNumber to, com.twilio.type.PhoneNumber from, java.util.List<java.net.URI> mediaUrl);
com.twilio.rest.api.v2010.account.MessageCreator creator(com.twilio.type.PhoneNumber to, String messagingServiceSid, String body);
com.twilio.rest.api.v2010.account.MessageCreator creator(com.twilio.type.PhoneNumber to, String messagingServiceSid, java.util.List<java.net.URI> mediaUrl);
com.twilio.rest.api.v2010.account.MessageCreator creator(com.twilio.type.PhoneNumber to, com.twilio.type.PhoneNumber from, String body);
com.twilio.rest.api.v2010.account.MessageCreator creator(com.twilio.type.PhoneNumber to, com.twilio.type.PhoneNumber from, java.util.List<java.net.URI> mediaUrl);
com.twilio.rest.api.v2010.account.MessageDeleter deleter(String pathAccountSid, String pathSid);
com.twilio.rest.api.v2010.account.MessageDeleter deleter(String pathSid);
com.twilio.rest.api.v2010.account.MessageFetcher fetcher(String pathAccountSid, String pathSid);
com.twilio.rest.api.v2010.account.MessageFetcher fetcher(String pathSid);
com.twilio.rest.api.v2010.account.MessageReader reader();
com.twilio.rest.api.v2010.account.MessageReader reader(String pathAccountSid);
com.twilio.rest.api.v2010.account.MessageUpdater updater(String pathAccountSid, String pathSid, String body);
com.twilio.rest.api.v2010.account.MessageUpdater updater(String pathSid, String body);
The message API is defined in the syntax as follows:
twilio:message/methodName?[parameters]
The 5 method(s) is listed in the table below. (API methods can have a shorthand alias name which can be used in the syntax instead of the name)
Method | Alias | Description |
---|---|---|
creator |
create |
Create a MessageCreator to execute create |
deleter |
delete |
Create a MessageDeleter to execute delete |
fetcher |
fetch |
Create a MessageFetcher to execute fetch |
reader |
read |
Create a MessageReader to execute read |
updater |
update |
Create a MessageUpdater to execute update |
The message API method(s) has the following set of parameters listed in the table below:
Method | Parameter | Description | Type |
---|---|---|---|
creator |
body |
The text of the message you want to send. Can be up to 1,600 characters in length. |
String |
creator |
from |
The phone number that initiated the message |
PhoneNumber |
creator |
mediaUrl |
The URL of the media to send with the message |
List |
creator |
messagingServiceSid |
The SID of the Messaging Service you want to associate with the message |
String |
creator |
pathAccountSid |
The SID of the Account that will create the resource |
String |
creator |
to |
The destination phone number |
PhoneNumber |
deleter |
pathAccountSid |
The SID of the Account that created the resources to delete |
String |
deleter |
pathSid |
The unique string that identifies the resource |
String |
fetcher |
pathAccountSid |
The SID of the Account that created the resource to fetch |
String |
fetcher |
pathSid |
The unique string that identifies the resource |
String |
reader |
pathAccountSid |
The SID of the Account that created the resources to read |
String |
updater |
body |
The text of the message you want to send |
String |
updater |
pathAccountSid |
The SID of the Account that created the resources to update |
String |
updater |
pathSid |
The unique string that identifies the resource |
String |
In addition to the parameters above, the message API can also use from the 21 endpoint query option which is listed in the Query Parameters section.
Any of the parameters can be provided in either the endpoint URI, or dynamically in a message header.
The message header name must be of the format CamelTwilio.parameter
.
The inBody
parameter overrides message header, i.e. the endpoint parameter inBody=myParameterNameHere
would override a CamelTwilio.myParameterNameHere
header.
API: message-feedback
Both producer and consumer are supported
The message-feedback API has 1 method(s) which is represented by the following method signatures (an API method may have multiple signatures due to overloading):
com.twilio.rest.api.v2010.account.message.FeedbackCreator creator(String pathAccountSid, String pathMessageSid);
com.twilio.rest.api.v2010.account.message.FeedbackCreator creator(String pathMessageSid);
The message-feedback API is defined in the syntax as follows:
twilio:message-feedback/methodName?[parameters]
The 1 method(s) is listed in the table below. (API methods can have a shorthand alias name which can be used in the syntax instead of the name)
Method | Alias | Description |
---|---|---|
creator |
create |
Create a FeedbackCreator to execute create |
The message-feedback API method(s) has the following set of parameters listed in the table below:
Method | Parameter | Description | Type |
---|---|---|---|
creator |
pathAccountSid |
The SID of the Account that will create the resource |
String |
creator |
pathMessageSid |
The SID of the Message resource for which the feedback was provided |
String |
In addition to the parameters above, the message-feedback API can also use from the 21 endpoint query option which is listed in the Query Parameters section.
Any of the parameters can be provided in either the endpoint URI, or dynamically in a message header.
The message header name must be of the format CamelTwilio.parameter
.
The inBody
parameter overrides message header, i.e. the endpoint parameter inBody=myParameterNameHere
would override a CamelTwilio.myParameterNameHere
header.
API: message-media
Both producer and consumer are supported
The message-media API has 3 method(s) which is represented by the following method signatures (an API method may have multiple signatures due to overloading):
com.twilio.rest.api.v2010.account.message.MediaDeleter deleter(String pathAccountSid, String pathMessageSid, String pathSid);
com.twilio.rest.api.v2010.account.message.MediaDeleter deleter(String pathMessageSid, String pathSid);
com.twilio.rest.api.v2010.account.message.MediaFetcher fetcher(String pathAccountSid, String pathMessageSid, String pathSid);
com.twilio.rest.api.v2010.account.message.MediaFetcher fetcher(String pathMessageSid, String pathSid);
com.twilio.rest.api.v2010.account.message.MediaReader reader(String pathAccountSid, String pathMessageSid);
com.twilio.rest.api.v2010.account.message.MediaReader reader(String pathMessageSid);
The message-media API is defined in the syntax as follows:
twilio:message-media/methodName?[parameters]
The 3 method(s) is listed in the table below. (API methods can have a shorthand alias name which can be used in the syntax instead of the name)
Method | Alias | Description |
---|---|---|
deleter |
delete |
Create a MediaDeleter to execute delete |
fetcher |
fetch |
Create a MediaFetcher to execute fetch |
reader |
read |
Create a MediaReader to execute read |
The message-media API method(s) has the following set of parameters listed in the table below:
Method | Parameter | Description | Type |
---|---|---|---|
deleter |
pathAccountSid |
The SID of the Account that created the resource(s) to delete |
String |
deleter |
pathMessageSid |
The SID of the Message resource that this Media resource belongs to |
String |
deleter |
pathSid |
The unique string that identifies this resource |
String |
fetcher |
pathAccountSid |
The SID of the Account that created the resource(s) to fetch |
String |
fetcher |
pathMessageSid |
The SID of the Message resource that this Media resource belongs to |
String |
fetcher |
pathSid |
The unique string that identifies this resource |
String |
reader |
pathAccountSid |
The SID of the Account that created the resource(s) to read |
String |
reader |
pathMessageSid |
The SID of the Message resource that this Media resource belongs to |
String |
In addition to the parameters above, the message-media API can also use from the 21 endpoint query option which is listed in the Query Parameters section.
Any of the parameters can be provided in either the endpoint URI, or dynamically in a message header.
The message header name must be of the format CamelTwilio.parameter
.
The inBody
parameter overrides message header, i.e. the endpoint parameter inBody=myParameterNameHere
would override a CamelTwilio.myParameterNameHere
header.
API: new-key
Both producer and consumer are supported
The new-key API has 1 method(s) which is represented by the following method signatures (an API method may have multiple signatures due to overloading):
com.twilio.rest.api.v2010.account.NewKeyCreator creator();
com.twilio.rest.api.v2010.account.NewKeyCreator creator(String pathAccountSid);
The new-key API is defined in the syntax as follows:
twilio:new-key/methodName?[parameters]
The 1 method(s) is listed in the table below. (API methods can have a shorthand alias name which can be used in the syntax instead of the name)
Method | Alias | Description |
---|---|---|
creator |
create |
Create a NewKeyCreator to execute create |
The new-key API method(s) has the following set of parameters listed in the table below:
Method | Parameter | Description | Type |
---|---|---|---|
creator |
pathAccountSid |
The SID of the Account that will be responsible for the new Key resource |
String |
In addition to the parameters above, the new-key API can also use from the 21 endpoint query option which is listed in the Query Parameters section.
Any of the parameters can be provided in either the endpoint URI, or dynamically in a message header.
The message header name must be of the format CamelTwilio.parameter
.
The inBody
parameter overrides message header, i.e. the endpoint parameter inBody=myParameterNameHere
would override a CamelTwilio.myParameterNameHere
header.
API: new-signing-key
Both producer and consumer are supported
The new-signing-key API has 1 method(s) which is represented by the following method signatures (an API method may have multiple signatures due to overloading):
com.twilio.rest.api.v2010.account.NewSigningKeyCreator creator();
com.twilio.rest.api.v2010.account.NewSigningKeyCreator creator(String pathAccountSid);
The new-signing-key API is defined in the syntax as follows:
twilio:new-signing-key/methodName?[parameters]
The 1 method(s) is listed in the table below. (API methods can have a shorthand alias name which can be used in the syntax instead of the name)
Method | Alias | Description |
---|---|---|
creator |
create |
Create a NewSigningKeyCreator to execute create |
The new-signing-key API method(s) has the following set of parameters listed in the table below:
Method | Parameter | Description | Type |
---|---|---|---|
creator |
pathAccountSid |
The SID of the Account that will be responsible for the new Key resource |
String |
In addition to the parameters above, the new-signing-key API can also use from the 21 endpoint query option which is listed in the Query Parameters section.
Any of the parameters can be provided in either the endpoint URI, or dynamically in a message header.
The message header name must be of the format CamelTwilio.parameter
.
The inBody
parameter overrides message header, i.e. the endpoint parameter inBody=myParameterNameHere
would override a CamelTwilio.myParameterNameHere
header.
API: notification
Both producer and consumer are supported
The notification API has 2 method(s) which is represented by the following method signatures (an API method may have multiple signatures due to overloading):
com.twilio.rest.api.v2010.account.NotificationFetcher fetcher(String pathAccountSid, String pathSid);
com.twilio.rest.api.v2010.account.NotificationFetcher fetcher(String pathSid);
com.twilio.rest.api.v2010.account.NotificationReader reader();
com.twilio.rest.api.v2010.account.NotificationReader reader(String pathAccountSid);
The notification API is defined in the syntax as follows:
twilio:notification/methodName?[parameters]
The 2 method(s) is listed in the table below. (API methods can have a shorthand alias name which can be used in the syntax instead of the name)
Method | Alias | Description |
---|---|---|
fetcher |
fetch |
Create a NotificationFetcher to execute fetch |
reader |
read |
Create a NotificationReader to execute read |
The notification API method(s) has the following set of parameters listed in the table below:
Method | Parameter | Description | Type |
---|---|---|---|
fetcher |
pathAccountSid |
The SID of the Account that created the resource to fetch |
String |
fetcher |
pathSid |
The unique string that identifies the resource |
String |
reader |
pathAccountSid |
The SID of the Account that created the resources to read |
String |
In addition to the parameters above, the notification API can also use from the 21 endpoint query option which is listed in the Query Parameters section.
Any of the parameters can be provided in either the endpoint URI, or dynamically in a message header.
The message header name must be of the format CamelTwilio.parameter
.
The inBody
parameter overrides message header, i.e. the endpoint parameter inBody=myParameterNameHere
would override a CamelTwilio.myParameterNameHere
header.
API: outgoing-caller-id
Both producer and consumer are supported
The outgoing-caller-id API has 4 method(s) which is represented by the following method signatures (an API method may have multiple signatures due to overloading):
com.twilio.rest.api.v2010.account.OutgoingCallerIdDeleter deleter(String pathAccountSid, String pathSid);
com.twilio.rest.api.v2010.account.OutgoingCallerIdDeleter deleter(String pathSid);
com.twilio.rest.api.v2010.account.OutgoingCallerIdFetcher fetcher(String pathAccountSid, String pathSid);
com.twilio.rest.api.v2010.account.OutgoingCallerIdFetcher fetcher(String pathSid);
com.twilio.rest.api.v2010.account.OutgoingCallerIdReader reader();
com.twilio.rest.api.v2010.account.OutgoingCallerIdReader reader(String pathAccountSid);
com.twilio.rest.api.v2010.account.OutgoingCallerIdUpdater updater(String pathAccountSid, String pathSid);
com.twilio.rest.api.v2010.account.OutgoingCallerIdUpdater updater(String pathSid);
The outgoing-caller-id API is defined in the syntax as follows:
twilio:outgoing-caller-id/methodName?[parameters]
The 4 method(s) is listed in the table below. (API methods can have a shorthand alias name which can be used in the syntax instead of the name)
Method | Alias | Description |
---|---|---|
deleter |
delete |
Create a OutgoingCallerIdDeleter to execute delete |
fetcher |
fetch |
Create a OutgoingCallerIdFetcher to execute fetch |
reader |
read |
Create a OutgoingCallerIdReader to execute read |
updater |
update |
Create a OutgoingCallerIdUpdater to execute update |
The outgoing-caller-id API method(s) has the following set of parameters listed in the table below:
Method | Parameter | Description | Type |
---|---|---|---|
deleter |
pathAccountSid |
The SID of the Account that created the resources to delete |
String |
deleter |
pathSid |
The unique string that identifies the resource |
String |
fetcher |
pathAccountSid |
The SID of the Account that created the resource to fetch |
String |
fetcher |
pathSid |
The unique string that identifies the resource |
String |
reader |
pathAccountSid |
The SID of the Account that created the resources to read |
String |
updater |
pathAccountSid |
The SID of the Account that created the resources to update |
String |
updater |
pathSid |
The unique string that identifies the resource |
String |
In addition to the parameters above, the outgoing-caller-id API can also use from the 21 endpoint query option which is listed in the Query Parameters section.
Any of the parameters can be provided in either the endpoint URI, or dynamically in a message header.
The message header name must be of the format CamelTwilio.parameter
.
The inBody
parameter overrides message header, i.e. the endpoint parameter inBody=myParameterNameHere
would override a CamelTwilio.myParameterNameHere
header.
API: queue
Both producer and consumer are supported
The queue API has 5 method(s) which is represented by the following method signatures (an API method may have multiple signatures due to overloading):
com.twilio.rest.api.v2010.account.QueueCreator creator(String friendlyName);
com.twilio.rest.api.v2010.account.QueueCreator creator(String pathAccountSid, String friendlyName);
com.twilio.rest.api.v2010.account.QueueDeleter deleter(String pathAccountSid, String pathSid);
com.twilio.rest.api.v2010.account.QueueDeleter deleter(String pathSid);
com.twilio.rest.api.v2010.account.QueueFetcher fetcher(String pathAccountSid, String pathSid);
com.twilio.rest.api.v2010.account.QueueFetcher fetcher(String pathSid);
com.twilio.rest.api.v2010.account.QueueReader reader();
com.twilio.rest.api.v2010.account.QueueReader reader(String pathAccountSid);
com.twilio.rest.api.v2010.account.QueueUpdater updater(String pathAccountSid, String pathSid);
com.twilio.rest.api.v2010.account.QueueUpdater updater(String pathSid);
The queue API is defined in the syntax as follows:
twilio:queue/methodName?[parameters]
The 5 method(s) is listed in the table below. (API methods can have a shorthand alias name which can be used in the syntax instead of the name)
Method | Alias | Description |
---|---|---|
creator |
create |
Create a QueueCreator to execute create |
deleter |
delete |
Create a QueueDeleter to execute delete |
fetcher |
fetch |
Create a QueueFetcher to execute fetch |
reader |
read |
Create a QueueReader to execute read |
updater |
update |
Create a QueueUpdater to execute update |
The queue API method(s) has the following set of parameters listed in the table below:
Method | Parameter | Description | Type |
---|---|---|---|
creator |
friendlyName |
A string to describe this resource |
String |
creator |
pathAccountSid |
The SID of the Account that will create the resource |
String |
deleter |
pathAccountSid |
The SID of the Account that created the resource(s) to delete |
String |
deleter |
pathSid |
The unique string that identifies this resource |
String |
fetcher |
pathAccountSid |
The SID of the Account that created the resource(s) to fetch |
String |
fetcher |
pathSid |
The unique string that identifies this resource |
String |
reader |
pathAccountSid |
The SID of the Account that created the resource(s) to fetch |
String |
updater |
pathAccountSid |
The SID of the Account that created the resource(s) to update |
String |
updater |
pathSid |
The unique string that identifies this resource |
String |
In addition to the parameters above, the queue API can also use from the 21 endpoint query option which is listed in the Query Parameters section.
Any of the parameters can be provided in either the endpoint URI, or dynamically in a message header.
The message header name must be of the format CamelTwilio.parameter
.
The inBody
parameter overrides message header, i.e. the endpoint parameter inBody=myParameterNameHere
would override a CamelTwilio.myParameterNameHere
header.
API: queue-member
Both producer and consumer are supported
The queue-member API has 3 method(s) which is represented by the following method signatures (an API method may have multiple signatures due to overloading):
com.twilio.rest.api.v2010.account.queue.MemberFetcher fetcher(String pathAccountSid, String pathQueueSid, String pathCallSid);
com.twilio.rest.api.v2010.account.queue.MemberFetcher fetcher(String pathQueueSid, String pathCallSid);
com.twilio.rest.api.v2010.account.queue.MemberReader reader(String pathAccountSid, String pathQueueSid);
com.twilio.rest.api.v2010.account.queue.MemberReader reader(String pathQueueSid);
com.twilio.rest.api.v2010.account.queue.MemberUpdater updater(String pathAccountSid, String pathQueueSid, String pathCallSid, java.net.URI url);
com.twilio.rest.api.v2010.account.queue.MemberUpdater updater(String pathQueueSid, String pathCallSid, java.net.URI url);
The queue-member API is defined in the syntax as follows:
twilio:queue-member/methodName?[parameters]
The 3 method(s) is listed in the table below. (API methods can have a shorthand alias name which can be used in the syntax instead of the name)
Method | Alias | Description |
---|---|---|
fetcher |
fetch |
Create a MemberFetcher to execute fetch |
reader |
read |
Create a MemberReader to execute read |
updater |
update |
Create a MemberUpdater to execute update |
The queue-member API method(s) has the following set of parameters listed in the table below:
Method | Parameter | Description | Type |
---|---|---|---|
fetcher |
pathAccountSid |
The SID of the Account that created the resource(s) to fetch |
String |
fetcher |
pathCallSid |
The Call SID of the resource(s) to fetch |
String |
fetcher |
pathQueueSid |
The SID of the Queue in which to find the members |
String |
reader |
pathAccountSid |
The SID of the Account that created the resource(s) to read |
String |
reader |
pathQueueSid |
The SID of the Queue in which to find the members |
String |
updater |
pathAccountSid |
The SID of the Account that created the resource(s) to update |
String |
updater |
pathCallSid |
The Call SID of the resource(s) to update |
String |
updater |
pathQueueSid |
The SID of the Queue in which to find the members |
String |
updater |
url |
The absolute URL of the Queue resource |
URI |
In addition to the parameters above, the queue-member API can also use from the 21 endpoint query option which is listed in the Query Parameters section.
Any of the parameters can be provided in either the endpoint URI, or dynamically in a message header.
The message header name must be of the format CamelTwilio.parameter
.
The inBody
parameter overrides message header, i.e. the endpoint parameter inBody=myParameterNameHere
would override a CamelTwilio.myParameterNameHere
header.
API: recording
Both producer and consumer are supported
The recording API has 3 method(s) which is represented by the following method signatures (an API method may have multiple signatures due to overloading):
com.twilio.rest.api.v2010.account.RecordingDeleter deleter(String pathAccountSid, String pathSid);
com.twilio.rest.api.v2010.account.RecordingDeleter deleter(String pathSid);
com.twilio.rest.api.v2010.account.RecordingFetcher fetcher(String pathAccountSid, String pathSid);
com.twilio.rest.api.v2010.account.RecordingFetcher fetcher(String pathSid);
com.twilio.rest.api.v2010.account.RecordingReader reader();
com.twilio.rest.api.v2010.account.RecordingReader reader(String pathAccountSid);
The recording API is defined in the syntax as follows:
twilio:recording/methodName?[parameters]
The 3 method(s) is listed in the table below. (API methods can have a shorthand alias name which can be used in the syntax instead of the name)
Method | Alias | Description |
---|---|---|
deleter |
delete |
Create a RecordingDeleter to execute delete |
fetcher |
fetch |
Create a RecordingFetcher to execute fetch |
reader |
read |
Create a RecordingReader to execute read |
The recording API method(s) has the following set of parameters listed in the table below:
Method | Parameter | Description | Type |
---|---|---|---|
deleter |
pathAccountSid |
The SID of the Account that created the resources to delete |
String |
deleter |
pathSid |
The unique string that identifies the resource |
String |
fetcher |
pathAccountSid |
The SID of the Account that created the resource to fetch |
String |
fetcher |
pathSid |
The unique string that identifies the resource |
String |
reader |
pathAccountSid |
The SID of the Account that created the resources to read |
String |
In addition to the parameters above, the recording API can also use from the 21 endpoint query option which is listed in the Query Parameters section.
Any of the parameters can be provided in either the endpoint URI, or dynamically in a message header.
The message header name must be of the format CamelTwilio.parameter
.
The inBody
parameter overrides message header, i.e. the endpoint parameter inBody=myParameterNameHere
would override a CamelTwilio.myParameterNameHere
header.
API: recording-add-on-result
Both producer and consumer are supported
The recording-add-on-result API has 3 method(s) which is represented by the following method signatures (an API method may have multiple signatures due to overloading):
com.twilio.rest.api.v2010.account.recording.AddOnResultDeleter deleter(String pathAccountSid, String pathReferenceSid, String pathSid);
com.twilio.rest.api.v2010.account.recording.AddOnResultDeleter deleter(String pathReferenceSid, String pathSid);
com.twilio.rest.api.v2010.account.recording.AddOnResultFetcher fetcher(String pathAccountSid, String pathReferenceSid, String pathSid);
com.twilio.rest.api.v2010.account.recording.AddOnResultFetcher fetcher(String pathReferenceSid, String pathSid);
com.twilio.rest.api.v2010.account.recording.AddOnResultReader reader(String pathAccountSid, String pathReferenceSid);
com.twilio.rest.api.v2010.account.recording.AddOnResultReader reader(String pathReferenceSid);
The recording-add-on-result API is defined in the syntax as follows:
twilio:recording-add-on-result/methodName?[parameters]
The 3 method(s) is listed in the table below. (API methods can have a shorthand alias name which can be used in the syntax instead of the name)
Method | Alias | Description |
---|---|---|
deleter |
delete |
Create a AddOnResultDeleter to execute delete |
fetcher |
fetch |
Create a AddOnResultFetcher to execute fetch |
reader |
read |
Create a AddOnResultReader to execute read |
The recording-add-on-result API method(s) has the following set of parameters listed in the table below:
Method | Parameter | Description | Type |
---|---|---|---|
deleter |
pathAccountSid |
The SID of the Account that created the resources to delete |
String |
deleter |
pathReferenceSid |
The SID of the recording to which the result to delete belongs |
String |
deleter |
pathSid |
The unique string that identifies the resource to delete |
String |
fetcher |
pathAccountSid |
The SID of the Account that created the resource to fetch |
String |
fetcher |
pathReferenceSid |
The SID of the recording to which the result to delete belongs |
String |
fetcher |
pathSid |
The unique string that identifies the resource to fetch |
String |
reader |
pathAccountSid |
The SID of the Account that created the resources to read |
String |
reader |
pathReferenceSid |
The SID of the recording to which the result to delete belongs |
String |
In addition to the parameters above, the recording-add-on-result API can also use from the 21 endpoint query option which is listed in the Query Parameters section.
Any of the parameters can be provided in either the endpoint URI, or dynamically in a message header.
The message header name must be of the format CamelTwilio.parameter
.
The inBody
parameter overrides message header, i.e. the endpoint parameter inBody=myParameterNameHere
would override a CamelTwilio.myParameterNameHere
header.
API: recording-add-on-result-payload
Both producer and consumer are supported
The recording-add-on-result-payload API has 3 method(s) which is represented by the following method signatures (an API method may have multiple signatures due to overloading):
com.twilio.rest.api.v2010.account.recording.addonresult.PayloadDeleter deleter(String pathAccountSid, String pathReferenceSid, String pathAddOnResultSid, String pathSid);
com.twilio.rest.api.v2010.account.recording.addonresult.PayloadDeleter deleter(String pathReferenceSid, String pathAddOnResultSid, String pathSid);
com.twilio.rest.api.v2010.account.recording.addonresult.PayloadFetcher fetcher(String pathAccountSid, String pathReferenceSid, String pathAddOnResultSid, String pathSid);
com.twilio.rest.api.v2010.account.recording.addonresult.PayloadFetcher fetcher(String pathReferenceSid, String pathAddOnResultSid, String pathSid);
com.twilio.rest.api.v2010.account.recording.addonresult.PayloadReader reader(String pathAccountSid, String pathReferenceSid, String pathAddOnResultSid);
com.twilio.rest.api.v2010.account.recording.addonresult.PayloadReader reader(String pathReferenceSid, String pathAddOnResultSid);
The recording-add-on-result-payload API is defined in the syntax as follows:
twilio:recording-add-on-result-payload/methodName?[parameters]
The 3 method(s) is listed in the table below. (API methods can have a shorthand alias name which can be used in the syntax instead of the name)
Method | Alias | Description |
---|---|---|
deleter |
delete |
Create a PayloadDeleter to execute delete |
fetcher |
fetch |
Create a PayloadFetcher to execute fetch |
reader |
read |
Create a PayloadReader to execute read |
The recording-add-on-result-payload API method(s) has the following set of parameters listed in the table below:
Method | Parameter | Description | Type |
---|---|---|---|
deleter |
pathAccountSid |
The SID of the Account that created the resources to delete |
String |
deleter |
pathAddOnResultSid |
The SID of the AddOnResult to which the payloads to delete belongs |
String |
deleter |
pathReferenceSid |
The SID of the recording to which the AddOnResult resource that contains the payloads to delete belongs |
String |
deleter |
pathSid |
The unique string that identifies the resource |
String |
fetcher |
pathAccountSid |
The SID of the Account that created the resource to fetch |
String |
fetcher |
pathAddOnResultSid |
The SID of the AddOnResult to which the payloads to delete belongs |
String |
fetcher |
pathReferenceSid |
The SID of the recording to which the AddOnResult resource that contains the payloads to delete belongs |
String |
fetcher |
pathSid |
The unique string that identifies the resource to fetch |
String |
reader |
pathAccountSid |
The SID of the Account that created the resources to read |
String |
reader |
pathAddOnResultSid |
The SID of the AddOnResult to which the payloads to delete belongs |
String |
reader |
pathReferenceSid |
The SID of the recording to which the AddOnResult resource that contains the payloads to delete belongs |
String |
In addition to the parameters above, the recording-add-on-result-payload API can also use from the 21 endpoint query option which is listed in the Query Parameters section.
Any of the parameters can be provided in either the endpoint URI, or dynamically in a message header.
The message header name must be of the format CamelTwilio.parameter
.
The inBody
parameter overrides message header, i.e. the endpoint parameter inBody=myParameterNameHere
would override a CamelTwilio.myParameterNameHere
header.
API: recording-transcription
Both producer and consumer are supported
The recording-transcription API has 3 method(s) which is represented by the following method signatures (an API method may have multiple signatures due to overloading):
com.twilio.rest.api.v2010.account.recording.TranscriptionDeleter deleter(String pathAccountSid, String pathRecordingSid, String pathSid);
com.twilio.rest.api.v2010.account.recording.TranscriptionDeleter deleter(String pathRecordingSid, String pathSid);
com.twilio.rest.api.v2010.account.recording.TranscriptionFetcher fetcher(String pathAccountSid, String pathRecordingSid, String pathSid);
com.twilio.rest.api.v2010.account.recording.TranscriptionFetcher fetcher(String pathRecordingSid, String pathSid);
com.twilio.rest.api.v2010.account.recording.TranscriptionReader reader(String pathAccountSid, String pathRecordingSid);
com.twilio.rest.api.v2010.account.recording.TranscriptionReader reader(String pathRecordingSid);
The recording-transcription API is defined in the syntax as follows:
twilio:recording-transcription/methodName?[parameters]
The 3 method(s) is listed in the table below. (API methods can have a shorthand alias name which can be used in the syntax instead of the name)
Method | Alias | Description |
---|---|---|
deleter |
delete |
Create a TranscriptionDeleter to execute delete |
fetcher |
fetch |
Create a TranscriptionFetcher to execute fetch |
reader |
read |
Create a TranscriptionReader to execute read |
The recording-transcription API method(s) has the following set of parameters listed in the table below:
Method | Parameter | Description | Type |
---|---|---|---|
deleter |
pathAccountSid |
The SID of the Account that created the resources to delete |
String |
deleter |
pathRecordingSid |
The SID of the recording that created the transcription to delete |
String |
deleter |
pathSid |
The unique string that identifies the resource |
String |
fetcher |
pathAccountSid |
The SID of the Account that created the resource to fetch |
String |
fetcher |
pathRecordingSid |
The SID of the recording that created the transcription to delete |
String |
fetcher |
pathSid |
The unique string that identifies the resource |
String |
reader |
pathAccountSid |
The SID of the Account that created the resources to read |
String |
reader |
pathRecordingSid |
The SID of the recording that created the transcription to delete |
String |
In addition to the parameters above, the recording-transcription API can also use from the 21 endpoint query option which is listed in the Query Parameters section.
Any of the parameters can be provided in either the endpoint URI, or dynamically in a message header.
The message header name must be of the format CamelTwilio.parameter
.
The inBody
parameter overrides message header, i.e. the endpoint parameter inBody=myParameterNameHere
would override a CamelTwilio.myParameterNameHere
header.
API: short-code
Both producer and consumer are supported
The short-code API has 3 method(s) which is represented by the following method signatures (an API method may have multiple signatures due to overloading):
com.twilio.rest.api.v2010.account.ShortCodeFetcher fetcher(String pathAccountSid, String pathSid);
com.twilio.rest.api.v2010.account.ShortCodeFetcher fetcher(String pathSid);
com.twilio.rest.api.v2010.account.ShortCodeReader reader();
com.twilio.rest.api.v2010.account.ShortCodeReader reader(String pathAccountSid);
com.twilio.rest.api.v2010.account.ShortCodeUpdater updater(String pathAccountSid, String pathSid);
com.twilio.rest.api.v2010.account.ShortCodeUpdater updater(String pathSid);
The short-code API is defined in the syntax as follows:
twilio:short-code/methodName?[parameters]
The 3 method(s) is listed in the table below. (API methods can have a shorthand alias name which can be used in the syntax instead of the name)
Method | Alias | Description |
---|---|---|
fetcher |
fetch |
Create a ShortCodeFetcher to execute fetch |
reader |
read |
Create a ShortCodeReader to execute read |
updater |
update |
Create a ShortCodeUpdater to execute update |
The short-code API method(s) has the following set of parameters listed in the table below:
Method | Parameter | Description | Type |
---|---|---|---|
fetcher |
pathAccountSid |
The SID of the Account that created the resource(s) to fetch |
String |
fetcher |
pathSid |
The unique string that identifies this resource |
String |
reader |
pathAccountSid |
The SID of the Account that created the resource(s) to read |
String |
updater |
pathAccountSid |
The SID of the Account that created the resource(s) to update |
String |
updater |
pathSid |
The unique string that identifies this resource |
String |
In addition to the parameters above, the short-code API can also use from the 21 endpoint query option which is listed in the Query Parameters section.
Any of the parameters can be provided in either the endpoint URI, or dynamically in a message header.
The message header name must be of the format CamelTwilio.parameter
.
The inBody
parameter overrides message header, i.e. the endpoint parameter inBody=myParameterNameHere
would override a CamelTwilio.myParameterNameHere
header.
API: signing-key
Both producer and consumer are supported
The signing-key API has 4 method(s) which is represented by the following method signatures (an API method may have multiple signatures due to overloading):
com.twilio.rest.api.v2010.account.SigningKeyDeleter deleter(String pathAccountSid, String pathSid);
com.twilio.rest.api.v2010.account.SigningKeyDeleter deleter(String pathSid);
com.twilio.rest.api.v2010.account.SigningKeyFetcher fetcher(String pathAccountSid, String pathSid);
com.twilio.rest.api.v2010.account.SigningKeyFetcher fetcher(String pathSid);
com.twilio.rest.api.v2010.account.SigningKeyReader reader();
com.twilio.rest.api.v2010.account.SigningKeyReader reader(String pathAccountSid);
com.twilio.rest.api.v2010.account.SigningKeyUpdater updater(String pathAccountSid, String pathSid);
com.twilio.rest.api.v2010.account.SigningKeyUpdater updater(String pathSid);
The signing-key API is defined in the syntax as follows:
twilio:signing-key/methodName?[parameters]
The 4 method(s) is listed in the table below. (API methods can have a shorthand alias name which can be used in the syntax instead of the name)
Method | Alias | Description |
---|---|---|
deleter |
delete |
Create a SigningKeyDeleter to execute delete |
fetcher |
fetch |
Create a SigningKeyFetcher to execute fetch |
reader |
read |
Create a SigningKeyReader to execute read |
updater |
update |
Create a SigningKeyUpdater to execute update |
The signing-key API method(s) has the following set of parameters listed in the table below:
Method | Parameter | Description | Type |
---|---|---|---|
deleter |
pathAccountSid |
The account_sid |
String |
deleter |
pathSid |
The sid |
String |
fetcher |
pathAccountSid |
The account_sid |
String |
fetcher |
pathSid |
The sid |
String |
reader |
pathAccountSid |
The account_sid |
String |
updater |
pathAccountSid |
The account_sid |
String |
updater |
pathSid |
The sid |
String |
In addition to the parameters above, the signing-key API can also use from the 21 endpoint query option which is listed in the Query Parameters section.
Any of the parameters can be provided in either the endpoint URI, or dynamically in a message header.
The message header name must be of the format CamelTwilio.parameter
.
The inBody
parameter overrides message header, i.e. the endpoint parameter inBody=myParameterNameHere
would override a CamelTwilio.myParameterNameHere
header.
API: sip-credential-list
Both producer and consumer are supported
The sip-credential-list API has 5 method(s) which is represented by the following method signatures (an API method may have multiple signatures due to overloading):
com.twilio.rest.api.v2010.account.sip.CredentialListCreator creator(String friendlyName);
com.twilio.rest.api.v2010.account.sip.CredentialListCreator creator(String pathAccountSid, String friendlyName);
com.twilio.rest.api.v2010.account.sip.CredentialListDeleter deleter(String pathAccountSid, String pathSid);
com.twilio.rest.api.v2010.account.sip.CredentialListDeleter deleter(String pathSid);
com.twilio.rest.api.v2010.account.sip.CredentialListFetcher fetcher(String pathAccountSid, String pathSid);
com.twilio.rest.api.v2010.account.sip.CredentialListFetcher fetcher(String pathSid);
com.twilio.rest.api.v2010.account.sip.CredentialListReader reader();
com.twilio.rest.api.v2010.account.sip.CredentialListReader reader(String pathAccountSid);
com.twilio.rest.api.v2010.account.sip.CredentialListUpdater updater(String pathAccountSid, String pathSid, String friendlyName);
com.twilio.rest.api.v2010.account.sip.CredentialListUpdater updater(String pathSid, String friendlyName);
The sip-credential-list API is defined in the syntax as follows:
twilio:sip-credential-list/methodName?[parameters]
The 5 method(s) is listed in the table below. (API methods can have a shorthand alias name which can be used in the syntax instead of the name)
Method | Alias | Description |
---|---|---|
creator |
create |
Create a CredentialListCreator to execute create |
deleter |
delete |
Create a CredentialListDeleter to execute delete |
fetcher |
fetch |
Create a CredentialListFetcher to execute fetch |
reader |
read |
Create a CredentialListReader to execute read |
updater |
update |
Create a CredentialListUpdater to execute update |
The sip-credential-list API method(s) has the following set of parameters listed in the table below:
Method | Parameter | Description | Type |
---|---|---|---|
creator |
friendlyName |
Human readable descriptive text |
String |
creator |
pathAccountSid |
The unique id of the Account that is responsible for this resource |
String |
deleter |
pathAccountSid |
The unique id of the Account that is responsible for this resource |
String |
deleter |
pathSid |
Delete by unique credential list Sid |
String |
fetcher |
pathAccountSid |
The unique id of the Account that is responsible for this resource |
String |
fetcher |
pathSid |
Fetch by unique credential list Sid |
String |
reader |
pathAccountSid |
The unique id of the Account that is responsible for this resource |
String |
updater |
friendlyName |
Human readable descriptive text |
String |
updater |
pathAccountSid |
The unique id of the Account that is responsible for this resource |
String |
updater |
pathSid |
Update by unique credential list Sid |
String |
In addition to the parameters above, the sip-credential-list API can also use from the 21 endpoint query option which is listed in the Query Parameters section.
Any of the parameters can be provided in either the endpoint URI, or dynamically in a message header.
The message header name must be of the format CamelTwilio.parameter
.
The inBody
parameter overrides message header, i.e. the endpoint parameter inBody=myParameterNameHere
would override a CamelTwilio.myParameterNameHere
header.
API: sip-credential-list-credential
Both producer and consumer are supported
The sip-credential-list-credential API has 5 method(s) which is represented by the following method signatures (an API method may have multiple signatures due to overloading):
com.twilio.rest.api.v2010.account.sip.credentiallist.CredentialCreator creator(String pathAccountSid, String pathCredentialListSid, String username, String password);
com.twilio.rest.api.v2010.account.sip.credentiallist.CredentialCreator creator(String pathCredentialListSid, String username, String password);
com.twilio.rest.api.v2010.account.sip.credentiallist.CredentialDeleter deleter(String pathAccountSid, String pathCredentialListSid, String pathSid);
com.twilio.rest.api.v2010.account.sip.credentiallist.CredentialDeleter deleter(String pathCredentialListSid, String pathSid);
com.twilio.rest.api.v2010.account.sip.credentiallist.CredentialFetcher fetcher(String pathAccountSid, String pathCredentialListSid, String pathSid);
com.twilio.rest.api.v2010.account.sip.credentiallist.CredentialFetcher fetcher(String pathCredentialListSid, String pathSid);
com.twilio.rest.api.v2010.account.sip.credentiallist.CredentialReader reader(String pathAccountSid, String pathCredentialListSid);
com.twilio.rest.api.v2010.account.sip.credentiallist.CredentialReader reader(String pathCredentialListSid);
com.twilio.rest.api.v2010.account.sip.credentiallist.CredentialUpdater updater(String pathAccountSid, String pathCredentialListSid, String pathSid);
com.twilio.rest.api.v2010.account.sip.credentiallist.CredentialUpdater updater(String pathCredentialListSid, String pathSid);
The sip-credential-list-credential API is defined in the syntax as follows:
twilio:sip-credential-list-credential/methodName?[parameters]
The 5 method(s) is listed in the table below. (API methods can have a shorthand alias name which can be used in the syntax instead of the name)
Method | Alias | Description |
---|---|---|
creator |
create |
Create a CredentialCreator to execute create |
deleter |
delete |
Create a CredentialDeleter to execute delete |
fetcher |
fetch |
Create a CredentialFetcher to execute fetch |
reader |
read |
Create a CredentialReader to execute read |
updater |
update |
Create a CredentialUpdater to execute update |
The sip-credential-list-credential API method(s) has the following set of parameters listed in the table below:
Method | Parameter | Description | Type |
---|---|---|---|
creator |
password |
The password will not be returned in the response |
String |
creator |
pathAccountSid |
The unique id of the Account that is responsible for this resource |
String |
creator |
pathCredentialListSid |
The unique id that identifies the credential list to include the created credential |
String |
creator |
username |
The username for this credential |
String |
deleter |
pathAccountSid |
The unique id of the Account that is responsible for this resource |
String |
deleter |
pathCredentialListSid |
The unique id that identifies the credential list to include the created credential |
String |
deleter |
pathSid |
The unique id that identifies the resource to delete |
String |
fetcher |
pathAccountSid |
The unique id of the Account that is responsible for this resource |
String |
fetcher |
pathCredentialListSid |
The unique id that identifies the credential list to include the created credential |
String |
fetcher |
pathSid |
The unique id that identifies the resource to fetch |
String |
reader |
pathAccountSid |
The unique id of the Account that is responsible for this resource |
String |
reader |
pathCredentialListSid |
The unique id that identifies the credential list to include the created credential |
String |
updater |
pathAccountSid |
The unique id of the Account that is responsible for this resource |
String |
updater |
pathCredentialListSid |
The unique id that identifies the credential list to include the created credential |
String |
updater |
pathSid |
The unique id that identifies the resource to update |
String |
In addition to the parameters above, the sip-credential-list-credential API can also use from the 21 endpoint query option which is listed in the Query Parameters section.
Any of the parameters can be provided in either the endpoint URI, or dynamically in a message header.
The message header name must be of the format CamelTwilio.parameter
.
The inBody
parameter overrides message header, i.e. the endpoint parameter inBody=myParameterNameHere
would override a CamelTwilio.myParameterNameHere
header.
API: sip-domain
Both producer and consumer are supported
The sip-domain API has 5 method(s) which is represented by the following method signatures (an API method may have multiple signatures due to overloading):
com.twilio.rest.api.v2010.account.sip.DomainCreator creator(String domainName);
com.twilio.rest.api.v2010.account.sip.DomainCreator creator(String pathAccountSid, String domainName);
com.twilio.rest.api.v2010.account.sip.DomainDeleter deleter(String pathAccountSid, String pathSid);
com.twilio.rest.api.v2010.account.sip.DomainDeleter deleter(String pathSid);
com.twilio.rest.api.v2010.account.sip.DomainFetcher fetcher(String pathAccountSid, String pathSid);
com.twilio.rest.api.v2010.account.sip.DomainFetcher fetcher(String pathSid);
com.twilio.rest.api.v2010.account.sip.DomainReader reader();
com.twilio.rest.api.v2010.account.sip.DomainReader reader(String pathAccountSid);
com.twilio.rest.api.v2010.account.sip.DomainUpdater updater(String pathAccountSid, String pathSid);
com.twilio.rest.api.v2010.account.sip.DomainUpdater updater(String pathSid);
The sip-domain API is defined in the syntax as follows:
twilio:sip-domain/methodName?[parameters]
The 5 method(s) is listed in the table below. (API methods can have a shorthand alias name which can be used in the syntax instead of the name)
Method | Alias | Description |
---|---|---|
creator |
create |
Create a DomainCreator to execute create |
deleter |
delete |
Create a DomainDeleter to execute delete |
fetcher |
fetch |
Create a DomainFetcher to execute fetch |
reader |
read |
Create a DomainReader to execute read |
updater |
update |
Create a DomainUpdater to execute update |
The sip-domain API method(s) has the following set of parameters listed in the table below:
Method | Parameter | Description | Type |
---|---|---|---|
creator |
domainName |
The unique address on Twilio to route SIP traffic |
String |
creator |
pathAccountSid |
The SID of the Account that will create the resource |
String |
deleter |
pathAccountSid |
The SID of the Account that created the resources to delete |
String |
deleter |
pathSid |
The unique string that identifies the resource |
String |
fetcher |
pathAccountSid |
The SID of the Account that created the resource to fetch |
String |
fetcher |
pathSid |
The unique string that identifies the resource |
String |
reader |
pathAccountSid |
The SID of the Account that created the resources to read |
String |
updater |
pathAccountSid |
The SID of the Account that created the resource to update |
String |
updater |
pathSid |
The unique string that identifies the resource |
String |
In addition to the parameters above, the sip-domain API can also use from the 21 endpoint query option which is listed in the Query Parameters section.
Any of the parameters can be provided in either the endpoint URI, or dynamically in a message header.
The message header name must be of the format CamelTwilio.parameter
.
The inBody
parameter overrides message header, i.e. the endpoint parameter inBody=myParameterNameHere
would override a CamelTwilio.myParameterNameHere
header.
API: sip-domain-credential-list-mapping
Both producer and consumer are supported
The sip-domain-credential-list-mapping API has 4 method(s) which is represented by the following method signatures (an API method may have multiple signatures due to overloading):
com.twilio.rest.api.v2010.account.sip.domain.CredentialListMappingCreator creator(String pathAccountSid, String pathDomainSid, String credentialListSid);
com.twilio.rest.api.v2010.account.sip.domain.CredentialListMappingCreator creator(String pathDomainSid, String credentialListSid);
com.twilio.rest.api.v2010.account.sip.domain.CredentialListMappingDeleter deleter(String pathAccountSid, String pathDomainSid, String pathSid);
com.twilio.rest.api.v2010.account.sip.domain.CredentialListMappingDeleter deleter(String pathDomainSid, String pathSid);
com.twilio.rest.api.v2010.account.sip.domain.CredentialListMappingFetcher fetcher(String pathAccountSid, String pathDomainSid, String pathSid);
com.twilio.rest.api.v2010.account.sip.domain.CredentialListMappingFetcher fetcher(String pathDomainSid, String pathSid);
com.twilio.rest.api.v2010.account.sip.domain.CredentialListMappingReader reader(String pathAccountSid, String pathDomainSid);
com.twilio.rest.api.v2010.account.sip.domain.CredentialListMappingReader reader(String pathDomainSid);
The sip-domain-credential-list-mapping API is defined in the syntax as follows:
twilio:sip-domain-credential-list-mapping/methodName?[parameters]
The 4 method(s) is listed in the table below. (API methods can have a shorthand alias name which can be used in the syntax instead of the name)
Method | Alias | Description |
---|---|---|
creator |
create |
Create a CredentialListMappingCreator to execute create |
deleter |
delete |
Create a CredentialListMappingDeleter to execute delete |
fetcher |
fetch |
Create a CredentialListMappingFetcher to execute fetch |
reader |
read |
Create a CredentialListMappingReader to execute read |
The sip-domain-credential-list-mapping API method(s) has the following set of parameters listed in the table below:
Method | Parameter | Description | Type |
---|---|---|---|
creator |
credentialListSid |
A string that identifies the CredentialList resource to map to the SIP domain |
String |
creator |
pathAccountSid |
The unique sid that identifies this account |
String |
creator |
pathDomainSid |
A string that identifies the SIP Domain for which the CredentialList resource will be mapped |
String |
deleter |
pathAccountSid |
The unique sid that identifies this account |
String |
deleter |
pathDomainSid |
A string that identifies the SIP Domain for which the CredentialList resource will be mapped |
String |
deleter |
pathSid |
A string that identifies the resource to delete |
String |
fetcher |
pathAccountSid |
The unique sid that identifies this account |
String |
fetcher |
pathDomainSid |
A string that identifies the SIP Domain for which the CredentialList resource will be mapped |
String |
fetcher |
pathSid |
A string that identifies the resource to fetch |
String |
reader |
pathAccountSid |
The unique sid that identifies this account |
String |
reader |
pathDomainSid |
A string that identifies the SIP Domain for which the CredentialList resource will be mapped |
String |
In addition to the parameters above, the sip-domain-credential-list-mapping API can also use from the 21 endpoint query option which is listed in the Query Parameters section.
Any of the parameters can be provided in either the endpoint URI, or dynamically in a message header.
The message header name must be of the format CamelTwilio.parameter
.
The inBody
parameter overrides message header, i.e. the endpoint parameter inBody=myParameterNameHere
would override a CamelTwilio.myParameterNameHere
header.
API: sip-domain-ip-access-control-list-mapping
Both producer and consumer are supported
The sip-domain-ip-access-control-list-mapping API has 4 method(s) which is represented by the following method signatures (an API method may have multiple signatures due to overloading):
com.twilio.rest.api.v2010.account.sip.domain.IpAccessControlListMappingCreator creator(String pathAccountSid, String pathDomainSid, String ipAccessControlListSid);
com.twilio.rest.api.v2010.account.sip.domain.IpAccessControlListMappingCreator creator(String pathDomainSid, String ipAccessControlListSid);
com.twilio.rest.api.v2010.account.sip.domain.IpAccessControlListMappingDeleter deleter(String pathAccountSid, String pathDomainSid, String pathSid);
com.twilio.rest.api.v2010.account.sip.domain.IpAccessControlListMappingDeleter deleter(String pathDomainSid, String pathSid);
com.twilio.rest.api.v2010.account.sip.domain.IpAccessControlListMappingFetcher fetcher(String pathAccountSid, String pathDomainSid, String pathSid);
com.twilio.rest.api.v2010.account.sip.domain.IpAccessControlListMappingFetcher fetcher(String pathDomainSid, String pathSid);
com.twilio.rest.api.v2010.account.sip.domain.IpAccessControlListMappingReader reader(String pathAccountSid, String pathDomainSid);
com.twilio.rest.api.v2010.account.sip.domain.IpAccessControlListMappingReader reader(String pathDomainSid);
The sip-domain-ip-access-control-list-mapping API is defined in the syntax as follows:
twilio:sip-domain-ip-access-control-list-mapping/methodName?[parameters]
The 4 method(s) is listed in the table below. (API methods can have a shorthand alias name which can be used in the syntax instead of the name)
Method | Alias | Description |
---|---|---|
creator |
create |
Create a IpAccessControlListMappingCreator to execute create |
deleter |
delete |
Create a IpAccessControlListMappingDeleter to execute delete |
fetcher |
fetch |
Create a IpAccessControlListMappingFetcher to execute fetch |
reader |
read |
Create a IpAccessControlListMappingReader to execute read |
The sip-domain-ip-access-control-list-mapping API method(s) has the following set of parameters listed in the table below:
Method | Parameter | Description | Type |
---|---|---|---|
creator |
ipAccessControlListSid |
The unique id of the IP access control list to map to the SIP domain |
String |
creator |
pathAccountSid |
The unique id of the Account that is responsible for this resource |
String |
creator |
pathDomainSid |
A string that uniquely identifies the SIP Domain |
String |
deleter |
pathAccountSid |
The unique id of the Account that is responsible for this resource |
String |
deleter |
pathDomainSid |
A string that uniquely identifies the SIP Domain |
String |
deleter |
pathSid |
A 34 character string that uniquely identifies the resource to delete. |
String |
fetcher |
pathAccountSid |
The unique id of the Account that is responsible for this resource |
String |
fetcher |
pathDomainSid |
A string that uniquely identifies the SIP Domain |
String |
fetcher |
pathSid |
A 34 character string that uniquely identifies the resource to fetch. |
String |
reader |
pathAccountSid |
The unique id of the Account that is responsible for this resource |
String |
reader |
pathDomainSid |
A string that uniquely identifies the SIP Domain |
String |
In addition to the parameters above, the sip-domain-ip-access-control-list-mapping API can also use from the 21 endpoint query option which is listed in the Query Parameters section.
Any of the parameters can be provided in either the endpoint URI, or dynamically in a message header.
The message header name must be of the format CamelTwilio.parameter
.
The inBody
parameter overrides message header, i.e. the endpoint parameter inBody=myParameterNameHere
would override a CamelTwilio.myParameterNameHere
header.
API: sip-ip-access-control-list
Both producer and consumer are supported
The sip-ip-access-control-list API has 5 method(s) which is represented by the following method signatures (an API method may have multiple signatures due to overloading):
com.twilio.rest.api.v2010.account.sip.IpAccessControlListCreator creator(String friendlyName);
com.twilio.rest.api.v2010.account.sip.IpAccessControlListCreator creator(String pathAccountSid, String friendlyName);
com.twilio.rest.api.v2010.account.sip.IpAccessControlListDeleter deleter(String pathAccountSid, String pathSid);
com.twilio.rest.api.v2010.account.sip.IpAccessControlListDeleter deleter(String pathSid);
com.twilio.rest.api.v2010.account.sip.IpAccessControlListFetcher fetcher(String pathAccountSid, String pathSid);
com.twilio.rest.api.v2010.account.sip.IpAccessControlListFetcher fetcher(String pathSid);
com.twilio.rest.api.v2010.account.sip.IpAccessControlListReader reader();
com.twilio.rest.api.v2010.account.sip.IpAccessControlListReader reader(String pathAccountSid);
com.twilio.rest.api.v2010.account.sip.IpAccessControlListUpdater updater(String pathAccountSid, String pathSid, String friendlyName);
com.twilio.rest.api.v2010.account.sip.IpAccessControlListUpdater updater(String pathSid, String friendlyName);
The sip-ip-access-control-list API is defined in the syntax as follows:
twilio:sip-ip-access-control-list/methodName?[parameters]
The 5 method(s) is listed in the table below. (API methods can have a shorthand alias name which can be used in the syntax instead of the name)
Method | Alias | Description |
---|---|---|
creator |
create |
Create a IpAccessControlListCreator to execute create |
deleter |
delete |
Create a IpAccessControlListDeleter to execute delete |
fetcher |
fetch |
Create a IpAccessControlListFetcher to execute fetch |
reader |
read |
Create a IpAccessControlListReader to execute read |
updater |
update |
Create a IpAccessControlListUpdater to execute update |
The sip-ip-access-control-list API method(s) has the following set of parameters listed in the table below:
Method | Parameter | Description | Type |
---|---|---|---|
creator |
friendlyName |
A human readable description of this resource |
String |
creator |
pathAccountSid |
The unique sid that identifies this account |
String |
deleter |
pathAccountSid |
The unique sid that identifies this account |
String |
deleter |
pathSid |
A string that identifies the resource to delete |
String |
fetcher |
pathAccountSid |
The unique sid that identifies this account |
String |
fetcher |
pathSid |
A string that identifies the resource to fetch |
String |
reader |
pathAccountSid |
The unique sid that identifies this account |
String |
updater |
friendlyName |
A human readable description of this resource |
String |
updater |
pathAccountSid |
The unique sid that identifies this account |
String |
updater |
pathSid |
A string that identifies the resource to update |
String |
In addition to the parameters above, the sip-ip-access-control-list API can also use from the 21 endpoint query option which is listed in the Query Parameters section.
Any of the parameters can be provided in either the endpoint URI, or dynamically in a message header.
The message header name must be of the format CamelTwilio.parameter
.
The inBody
parameter overrides message header, i.e. the endpoint parameter inBody=myParameterNameHere
would override a CamelTwilio.myParameterNameHere
header.
API: sip-ip-access-control-list-ip-address
Both producer and consumer are supported
The sip-ip-access-control-list-ip-address API has 5 method(s) which is represented by the following method signatures (an API method may have multiple signatures due to overloading):
com.twilio.rest.api.v2010.account.sip.ipaccesscontrollist.IpAddressCreator creator(String pathAccountSid, String pathIpAccessControlListSid, String friendlyName, String ipAddress);
com.twilio.rest.api.v2010.account.sip.ipaccesscontrollist.IpAddressCreator creator(String pathIpAccessControlListSid, String friendlyName, String ipAddress);
com.twilio.rest.api.v2010.account.sip.ipaccesscontrollist.IpAddressDeleter deleter(String pathAccountSid, String pathIpAccessControlListSid, String pathSid);
com.twilio.rest.api.v2010.account.sip.ipaccesscontrollist.IpAddressDeleter deleter(String pathIpAccessControlListSid, String pathSid);
com.twilio.rest.api.v2010.account.sip.ipaccesscontrollist.IpAddressFetcher fetcher(String pathAccountSid, String pathIpAccessControlListSid, String pathSid);
com.twilio.rest.api.v2010.account.sip.ipaccesscontrollist.IpAddressFetcher fetcher(String pathIpAccessControlListSid, String pathSid);
com.twilio.rest.api.v2010.account.sip.ipaccesscontrollist.IpAddressReader reader(String pathAccountSid, String pathIpAccessControlListSid);
com.twilio.rest.api.v2010.account.sip.ipaccesscontrollist.IpAddressReader reader(String pathIpAccessControlListSid);
com.twilio.rest.api.v2010.account.sip.ipaccesscontrollist.IpAddressUpdater updater(String pathAccountSid, String pathIpAccessControlListSid, String pathSid);
com.twilio.rest.api.v2010.account.sip.ipaccesscontrollist.IpAddressUpdater updater(String pathIpAccessControlListSid, String pathSid);
The sip-ip-access-control-list-ip-address API is defined in the syntax as follows:
twilio:sip-ip-access-control-list-ip-address/methodName?[parameters]
The 5 method(s) is listed in the table below. (API methods can have a shorthand alias name which can be used in the syntax instead of the name)
Method | Alias | Description |
---|---|---|
creator |
create |
Create a IpAddressCreator to execute create |
deleter |
delete |
Create a IpAddressDeleter to execute delete |
fetcher |
fetch |
Create a IpAddressFetcher to execute fetch |
reader |
read |
Create a IpAddressReader to execute read |
updater |
update |
Create a IpAddressUpdater to execute update |
The sip-ip-access-control-list-ip-address API method(s) has the following set of parameters listed in the table below:
Method | Parameter | Description | Type |
---|---|---|---|
creator |
friendlyName |
A human readable descriptive text for this resource, up to 64 characters long. |
String |
creator |
ipAddress |
An IP address in dotted decimal notation from which you want to accept traffic. Any SIP requests from this IP address will be allowed by Twilio. IPv4 only supported today. |
String |
creator |
pathAccountSid |
The unique sid that identifies this account |
String |
creator |
pathIpAccessControlListSid |
The IpAccessControlList Sid with which to associate the created IpAddress resource |
String |
deleter |
pathAccountSid |
The unique sid that identifies this account |
String |
deleter |
pathIpAccessControlListSid |
The IpAccessControlList Sid with which to associate the created IpAddress resource |
String |
deleter |
pathSid |
A string that identifies the resource to delete |
String |
fetcher |
pathAccountSid |
The unique sid that identifies this account |
String |
fetcher |
pathIpAccessControlListSid |
The IpAccessControlList Sid with which to associate the created IpAddress resource |
String |
fetcher |
pathSid |
A string that identifies the IpAddress resource to fetch |
String |
reader |
pathAccountSid |
The unique sid that identifies this account |
String |
reader |
pathIpAccessControlListSid |
The IpAccessControlList Sid with which to associate the created IpAddress resource |
String |
updater |
pathAccountSid |
The unique sid that identifies this account |
String |
updater |
pathIpAccessControlListSid |
The IpAccessControlList Sid with which to associate the created IpAddress resource |
String |
updater |
pathSid |
A string that identifies the IpAddress resource to update |
String |
In addition to the parameters above, the sip-ip-access-control-list-ip-address API can also use from the 21 endpoint query option which is listed in the Query Parameters section.
Any of the parameters can be provided in either the endpoint URI, or dynamically in a message header.
The message header name must be of the format CamelTwilio.parameter
.
The inBody
parameter overrides message header, i.e. the endpoint parameter inBody=myParameterNameHere
would override a CamelTwilio.myParameterNameHere
header.
API: token
Both producer and consumer are supported
The token API has 1 method(s) which is represented by the following method signatures (an API method may have multiple signatures due to overloading):
com.twilio.rest.api.v2010.account.TokenCreator creator();
com.twilio.rest.api.v2010.account.TokenCreator creator(String pathAccountSid);
The token API is defined in the syntax as follows:
twilio:token/methodName?[parameters]
The 1 method(s) is listed in the table below. (API methods can have a shorthand alias name which can be used in the syntax instead of the name)
Method | Alias | Description |
---|---|---|
creator |
create |
Create a TokenCreator to execute create |
The token API method(s) has the following set of parameters listed in the table below:
Method | Parameter | Description | Type |
---|---|---|---|
creator |
pathAccountSid |
The SID of the Account that will create the resource |
String |
In addition to the parameters above, the token API can also use from the 21 endpoint query option which is listed in the Query Parameters section.
Any of the parameters can be provided in either the endpoint URI, or dynamically in a message header.
The message header name must be of the format CamelTwilio.parameter
.
The inBody
parameter overrides message header, i.e. the endpoint parameter inBody=myParameterNameHere
would override a CamelTwilio.myParameterNameHere
header.
API: transcription
Both producer and consumer are supported
The transcription API has 3 method(s) which is represented by the following method signatures (an API method may have multiple signatures due to overloading):
com.twilio.rest.api.v2010.account.TranscriptionDeleter deleter(String pathAccountSid, String pathSid);
com.twilio.rest.api.v2010.account.TranscriptionDeleter deleter(String pathSid);
com.twilio.rest.api.v2010.account.TranscriptionFetcher fetcher(String pathAccountSid, String pathSid);
com.twilio.rest.api.v2010.account.TranscriptionFetcher fetcher(String pathSid);
com.twilio.rest.api.v2010.account.TranscriptionReader reader();
com.twilio.rest.api.v2010.account.TranscriptionReader reader(String pathAccountSid);
The transcription API is defined in the syntax as follows:
twilio:transcription/methodName?[parameters]
The 3 method(s) is listed in the table below. (API methods can have a shorthand alias name which can be used in the syntax instead of the name)
Method | Alias | Description |
---|---|---|
deleter |
delete |
Create a TranscriptionDeleter to execute delete |
fetcher |
fetch |
Create a TranscriptionFetcher to execute fetch |
reader |
read |
Create a TranscriptionReader to execute read |
The transcription API method(s) has the following set of parameters listed in the table below:
Method | Parameter | Description | Type |
---|---|---|---|
deleter |
pathAccountSid |
The SID of the Account that created the resources to delete |
String |
deleter |
pathSid |
The unique string that identifies the resource |
String |
fetcher |
pathAccountSid |
The SID of the Account that created the resource to fetch |
String |
fetcher |
pathSid |
The unique string that identifies the resource |
String |
reader |
pathAccountSid |
The SID of the Account that created the resources to read |
String |
In addition to the parameters above, the transcription API can also use from the 21 endpoint query option which is listed in the Query Parameters section.
Any of the parameters can be provided in either the endpoint URI, or dynamically in a message header.
The message header name must be of the format CamelTwilio.parameter
.
The inBody
parameter overrides message header, i.e. the endpoint parameter inBody=myParameterNameHere
would override a CamelTwilio.myParameterNameHere
header.
API: usage-record
Both producer and consumer are supported
The usage-record API has 1 method(s) which is represented by the following method signatures (an API method may have multiple signatures due to overloading):
com.twilio.rest.api.v2010.account.usage.RecordReader reader();
com.twilio.rest.api.v2010.account.usage.RecordReader reader(String pathAccountSid);
The usage-record API is defined in the syntax as follows:
twilio:usage-record/methodName?[parameters]
The 1 method(s) is listed in the table below. (API methods can have a shorthand alias name which can be used in the syntax instead of the name)
Method | Alias | Description |
---|---|---|
reader |
read |
Create a RecordReader to execute read |
The usage-record API method(s) has the following set of parameters listed in the table below:
Method | Parameter | Description | Type |
---|---|---|---|
reader |
pathAccountSid |
The SID of the Account that created the resources to read |
String |
In addition to the parameters above, the usage-record API can also use from the 21 endpoint query option which is listed in the Query Parameters section.
Any of the parameters can be provided in either the endpoint URI, or dynamically in a message header.
The message header name must be of the format CamelTwilio.parameter
.
The inBody
parameter overrides message header, i.e. the endpoint parameter inBody=myParameterNameHere
would override a CamelTwilio.myParameterNameHere
header.
API: usage-record-all-time
Both producer and consumer are supported
The usage-record-all-time API has 1 method(s) which is represented by the following method signatures (an API method may have multiple signatures due to overloading):
com.twilio.rest.api.v2010.account.usage.record.AllTimeReader reader();
com.twilio.rest.api.v2010.account.usage.record.AllTimeReader reader(String pathAccountSid);
The usage-record-all-time API is defined in the syntax as follows:
twilio:usage-record-all-time/methodName?[parameters]
The 1 method(s) is listed in the table below. (API methods can have a shorthand alias name which can be used in the syntax instead of the name)
Method | Alias | Description |
---|---|---|
reader |
read |
Create a AllTimeReader to execute read |
The usage-record-all-time API method(s) has the following set of parameters listed in the table below:
Method | Parameter | Description | Type |
---|---|---|---|
reader |
pathAccountSid |
The SID of the Account that created the resources to read |
String |
In addition to the parameters above, the usage-record-all-time API can also use from the 21 endpoint query option which is listed in the Query Parameters section.
Any of the parameters can be provided in either the endpoint URI, or dynamically in a message header.
The message header name must be of the format CamelTwilio.parameter
.
The inBody
parameter overrides message header, i.e. the endpoint parameter inBody=myParameterNameHere
would override a CamelTwilio.myParameterNameHere
header.
API: usage-record-daily
Both producer and consumer are supported
The usage-record-daily API has 1 method(s) which is represented by the following method signatures (an API method may have multiple signatures due to overloading):
com.twilio.rest.api.v2010.account.usage.record.DailyReader reader();
com.twilio.rest.api.v2010.account.usage.record.DailyReader reader(String pathAccountSid);
The usage-record-daily API is defined in the syntax as follows:
twilio:usage-record-daily/methodName?[parameters]
The 1 method(s) is listed in the table below. (API methods can have a shorthand alias name which can be used in the syntax instead of the name)
Method | Alias | Description |
---|---|---|
reader |
read |
Create a DailyReader to execute read |
The usage-record-daily API method(s) has the following set of parameters listed in the table below:
Method | Parameter | Description | Type |
---|---|---|---|
reader |
pathAccountSid |
The SID of the Account that created the resources to read |
String |
In addition to the parameters above, the usage-record-daily API can also use from the 21 endpoint query option which is listed in the Query Parameters section.
Any of the parameters can be provided in either the endpoint URI, or dynamically in a message header.
The message header name must be of the format CamelTwilio.parameter
.
The inBody
parameter overrides message header, i.e. the endpoint parameter inBody=myParameterNameHere
would override a CamelTwilio.myParameterNameHere
header.
API: usage-record-last-month
Both producer and consumer are supported
The usage-record-last-month API has 1 method(s) which is represented by the following method signatures (an API method may have multiple signatures due to overloading):
com.twilio.rest.api.v2010.account.usage.record.LastMonthReader reader();
com.twilio.rest.api.v2010.account.usage.record.LastMonthReader reader(String pathAccountSid);
The usage-record-last-month API is defined in the syntax as follows:
twilio:usage-record-last-month/methodName?[parameters]
The 1 method(s) is listed in the table below. (API methods can have a shorthand alias name which can be used in the syntax instead of the name)
Method | Alias | Description |
---|---|---|
reader |
read |
Create a LastMonthReader to execute read |
The usage-record-last-month API method(s) has the following set of parameters listed in the table below:
Method | Parameter | Description | Type |
---|---|---|---|
reader |
pathAccountSid |
The SID of the Account that created the resources to read |
String |
In addition to the parameters above, the usage-record-last-month API can also use from the 21 endpoint query option which is listed in the Query Parameters section.
Any of the parameters can be provided in either the endpoint URI, or dynamically in a message header.
The message header name must be of the format CamelTwilio.parameter
.
The inBody
parameter overrides message header, i.e. the endpoint parameter inBody=myParameterNameHere
would override a CamelTwilio.myParameterNameHere
header.
API: usage-record-monthly
Both producer and consumer are supported
The usage-record-monthly API has 1 method(s) which is represented by the following method signatures (an API method may have multiple signatures due to overloading):
com.twilio.rest.api.v2010.account.usage.record.MonthlyReader reader();
com.twilio.rest.api.v2010.account.usage.record.MonthlyReader reader(String pathAccountSid);
The usage-record-monthly API is defined in the syntax as follows:
twilio:usage-record-monthly/methodName?[parameters]
The 1 method(s) is listed in the table below. (API methods can have a shorthand alias name which can be used in the syntax instead of the name)
Method | Alias | Description |
---|---|---|
reader |
read |
Create a MonthlyReader to execute read |
The usage-record-monthly API method(s) has the following set of parameters listed in the table below:
Method | Parameter | Description | Type |
---|---|---|---|
reader |
pathAccountSid |
The SID of the Account that created the resources to read |
String |
In addition to the parameters above, the usage-record-monthly API can also use from the 21 endpoint query option which is listed in the Query Parameters section.
Any of the parameters can be provided in either the endpoint URI, or dynamically in a message header.
The message header name must be of the format CamelTwilio.parameter
.
The inBody
parameter overrides message header, i.e. the endpoint parameter inBody=myParameterNameHere
would override a CamelTwilio.myParameterNameHere
header.
API: usage-record-this-month
Both producer and consumer are supported
The usage-record-this-month API has 1 method(s) which is represented by the following method signatures (an API method may have multiple signatures due to overloading):
com.twilio.rest.api.v2010.account.usage.record.ThisMonthReader reader();
com.twilio.rest.api.v2010.account.usage.record.ThisMonthReader reader(String pathAccountSid);
The usage-record-this-month API is defined in the syntax as follows:
twilio:usage-record-this-month/methodName?[parameters]
The 1 method(s) is listed in the table below. (API methods can have a shorthand alias name which can be used in the syntax instead of the name)
Method | Alias | Description |
---|---|---|
reader |
read |
Create a ThisMonthReader to execute read |
The usage-record-this-month API method(s) has the following set of parameters listed in the table below:
Method | Parameter | Description | Type |
---|---|---|---|
reader |
pathAccountSid |
The SID of the Account that created the resources to read |
String |
In addition to the parameters above, the usage-record-this-month API can also use from the 21 endpoint query option which is listed in the Query Parameters section.
Any of the parameters can be provided in either the endpoint URI, or dynamically in a message header.
The message header name must be of the format CamelTwilio.parameter
.
The inBody
parameter overrides message header, i.e. the endpoint parameter inBody=myParameterNameHere
would override a CamelTwilio.myParameterNameHere
header.
API: usage-record-today
Both producer and consumer are supported
The usage-record-today API has 1 method(s) which is represented by the following method signatures (an API method may have multiple signatures due to overloading):
com.twilio.rest.api.v2010.account.usage.record.TodayReader reader();
com.twilio.rest.api.v2010.account.usage.record.TodayReader reader(String pathAccountSid);
The usage-record-today API is defined in the syntax as follows:
twilio:usage-record-today/methodName?[parameters]
The 1 method(s) is listed in the table below. (API methods can have a shorthand alias name which can be used in the syntax instead of the name)
Method | Alias | Description |
---|---|---|
reader |
read |
Create a TodayReader to execute read |
The usage-record-today API method(s) has the following set of parameters listed in the table below:
Method | Parameter | Description | Type |
---|---|---|---|
reader |
pathAccountSid |
The SID of the Account that created the resources to read |
String |
In addition to the parameters above, the usage-record-today API can also use from the 21 endpoint query option which is listed in the Query Parameters section.
Any of the parameters can be provided in either the endpoint URI, or dynamically in a message header.
The message header name must be of the format CamelTwilio.parameter
.
The inBody
parameter overrides message header, i.e. the endpoint parameter inBody=myParameterNameHere
would override a CamelTwilio.myParameterNameHere
header.
API: usage-record-yearly
Both producer and consumer are supported
The usage-record-yearly API has 1 method(s) which is represented by the following method signatures (an API method may have multiple signatures due to overloading):
com.twilio.rest.api.v2010.account.usage.record.YearlyReader reader();
com.twilio.rest.api.v2010.account.usage.record.YearlyReader reader(String pathAccountSid);
The usage-record-yearly API is defined in the syntax as follows:
twilio:usage-record-yearly/methodName?[parameters]
The 1 method(s) is listed in the table below. (API methods can have a shorthand alias name which can be used in the syntax instead of the name)
Method | Alias | Description |
---|---|---|
reader |
read |
Create a YearlyReader to execute read |
The usage-record-yearly API method(s) has the following set of parameters listed in the table below:
Method | Parameter | Description | Type |
---|---|---|---|
reader |
pathAccountSid |
The SID of the Account that created the resources to read |
String |
In addition to the parameters above, the usage-record-yearly API can also use from the 21 endpoint query option which is listed in the Query Parameters section.
Any of the parameters can be provided in either the endpoint URI, or dynamically in a message header.
The message header name must be of the format CamelTwilio.parameter
.
The inBody
parameter overrides message header, i.e. the endpoint parameter inBody=myParameterNameHere
would override a CamelTwilio.myParameterNameHere
header.
API: usage-record-yesterday
Both producer and consumer are supported
The usage-record-yesterday API has 1 method(s) which is represented by the following method signatures (an API method may have multiple signatures due to overloading):
com.twilio.rest.api.v2010.account.usage.record.YesterdayReader reader();
com.twilio.rest.api.v2010.account.usage.record.YesterdayReader reader(String pathAccountSid);
The usage-record-yesterday API is defined in the syntax as follows:
twilio:usage-record-yesterday/methodName?[parameters]
The 1 method(s) is listed in the table below. (API methods can have a shorthand alias name which can be used in the syntax instead of the name)
Method | Alias | Description |
---|---|---|
reader |
read |
Create a YesterdayReader to execute read |
The usage-record-yesterday API method(s) has the following set of parameters listed in the table below:
Method | Parameter | Description | Type |
---|---|---|---|
reader |
pathAccountSid |
The SID of the Account that created the resources to read |
String |
In addition to the parameters above, the usage-record-yesterday API can also use from the 21 endpoint query option which is listed in the Query Parameters section.
Any of the parameters can be provided in either the endpoint URI, or dynamically in a message header.
The message header name must be of the format CamelTwilio.parameter
.
The inBody
parameter overrides message header, i.e. the endpoint parameter inBody=myParameterNameHere
would override a CamelTwilio.myParameterNameHere
header.
API: usage-trigger
Both producer and consumer are supported
The usage-trigger API has 5 method(s) which is represented by the following method signatures (an API method may have multiple signatures due to overloading):
com.twilio.rest.api.v2010.account.usage.TriggerCreator creator(String pathAccountSid, java.net.URI callbackUrl, String triggerValue, com.twilio.rest.api.v2010.account.usage.Trigger.UsageCategory usageCategory);
com.twilio.rest.api.v2010.account.usage.TriggerCreator creator(java.net.URI callbackUrl, String triggerValue, com.twilio.rest.api.v2010.account.usage.Trigger.UsageCategory usageCategory);
com.twilio.rest.api.v2010.account.usage.TriggerDeleter deleter(String pathAccountSid, String pathSid);
com.twilio.rest.api.v2010.account.usage.TriggerDeleter deleter(String pathSid);
com.twilio.rest.api.v2010.account.usage.TriggerFetcher fetcher(String pathAccountSid, String pathSid);
com.twilio.rest.api.v2010.account.usage.TriggerFetcher fetcher(String pathSid);
com.twilio.rest.api.v2010.account.usage.TriggerReader reader();
com.twilio.rest.api.v2010.account.usage.TriggerReader reader(String pathAccountSid);
com.twilio.rest.api.v2010.account.usage.TriggerUpdater updater(String pathAccountSid, String pathSid);
com.twilio.rest.api.v2010.account.usage.TriggerUpdater updater(String pathSid);
The usage-trigger API is defined in the syntax as follows:
twilio:usage-trigger/methodName?[parameters]
The 5 method(s) is listed in the table below. (API methods can have a shorthand alias name which can be used in the syntax instead of the name)
Method | Alias | Description |
---|---|---|
creator |
create |
Create a TriggerCreator to execute create |
deleter |
delete |
Create a TriggerDeleter to execute delete |
fetcher |
fetch |
Create a TriggerFetcher to execute fetch |
reader |
read |
Create a TriggerReader to execute read |
updater |
update |
Create a TriggerUpdater to execute update |
The usage-trigger API method(s) has the following set of parameters listed in the table below:
Method | Parameter | Description | Type |
---|---|---|---|
creator |
callbackUrl |
The URL we call when the trigger fires |
URI |
creator |
pathAccountSid |
The SID of the Account that will create the resource |
String |
creator |
triggerValue |
The usage value at which the trigger should fire |
String |
creator |
usageCategory |
The usage category the trigger watches |
UsageCategory |
deleter |
pathAccountSid |
The SID of the Account that created the resources to delete |
String |
deleter |
pathSid |
The unique string that identifies the resource |
String |
fetcher |
pathAccountSid |
The SID of the Account that created the resource to fetch |
String |
fetcher |
pathSid |
The unique string that identifies the resource |
String |
reader |
pathAccountSid |
The SID of the Account that created the resources to read |
String |
updater |
pathAccountSid |
The SID of the Account that created the resources to update |
String |
updater |
pathSid |
The unique string that identifies the resource |
String |
In addition to the parameters above, the usage-trigger API can also use from the 21 endpoint query option which is listed in the Query Parameters section.
Any of the parameters can be provided in either the endpoint URI, or dynamically in a message header.
The message header name must be of the format CamelTwilio.parameter
.
The inBody
parameter overrides message header, i.e. the endpoint parameter inBody=myParameterNameHere
would override a CamelTwilio.myParameterNameHere
header.
API: validation-request
Both producer and consumer are supported
The validation-request API has 1 method(s) which is represented by the following method signatures (an API method may have multiple signatures due to overloading):
com.twilio.rest.api.v2010.account.ValidationRequestCreator creator(String pathAccountSid, com.twilio.type.PhoneNumber phoneNumber);
com.twilio.rest.api.v2010.account.ValidationRequestCreator creator(com.twilio.type.PhoneNumber phoneNumber);
The validation-request API is defined in the syntax as follows:
twilio:validation-request/methodName?[parameters]
The 1 method(s) is listed in the table below. (API methods can have a shorthand alias name which can be used in the syntax instead of the name)
Method | Alias | Description |
---|---|---|
creator |
create |
Create a ValidationRequestCreator to execute create |
The validation-request API method(s) has the following set of parameters listed in the table below:
Method | Parameter | Description | Type |
---|---|---|---|
creator |
pathAccountSid |
The SID of the Account responsible for the new Caller ID |
String |
creator |
phoneNumber |
The phone number to verify in E.164 format |
PhoneNumber |
In addition to the parameters above, the validation-request API can also use from the 21 endpoint query option which is listed in the Query Parameters section.
Any of the parameters can be provided in either the endpoint URI, or dynamically in a message header.
The message header name must be of the format CamelTwilio.parameter
.
The inBody
parameter overrides message header, i.e. the endpoint parameter inBody=myParameterNameHere
would override a CamelTwilio.myParameterNameHere
header.
Producer Endpoints:
Producer endpoints can use endpoint prefixes followed by endpoint names and associated options described next. A shorthand alias can be used for all of the endpoints. The endpoint URI MUST contain a prefix.
Any of the endpoint options can be provided in either the endpoint URI,
or dynamically in a message header. The message header name must be of
the format CamelTwilio.<option>
. Note that the inBody
option
overrides message header, i.e. the endpoint option inBody=option
would override a CamelTwilio.option
header.
Endpoint can be one of:
Endpoint | Shorthand Alias | Description |
---|---|---|
creator |
create |
Make the request to the Twilio API to perform the create |
deleter |
delete |
Make the request to the Twilio API to perform the delete |
fetcher |
fetch |
Make the request to the Twilio API to perform the fetch |
reader |
read |
Make the request to the Twilio API to perform the read |
updater |
update |
Make the request to the Twilio API to perform the update |
Available endpoints differ depending on the endpoint prefixes.
For more information on the endpoints and options see API documentation at: https://www.twilio.com/docs/libraries/reference/twilio-java/index.html
Spring Boot Auto-Configuration
When using twilio with Spring Boot make sure to use the following Maven dependency to have support for auto configuration:
<dependency>
<groupId>org.apache.camel.springboot</groupId>
<artifactId>camel-twilio-starter</artifactId>
<version>x.x.x</version>
<!-- use the same version as your Camel core version -->
</dependency>
The component supports 9 options, which are listed below.
Name | Description | Default | Type |
---|---|---|---|
camel.component.twilio.account-sid |
The account SID to use. |
String |
|
camel.component.twilio.autowired-enabled |
Whether autowiring is enabled. This is used for automatic autowiring options (the option must be marked as autowired) by looking up in the registry to find if there is a single instance of matching type, which then gets configured on the component. This can be used for automatic configuring JDBC data sources, JMS connection factories, AWS Clients, etc. |
true |
Boolean |
camel.component.twilio.bridge-error-handler |
Allows for bridging the consumer to the Camel routing Error Handler, which mean any exceptions occurred while the consumer is trying to pickup incoming messages, or the likes, will now be processed as a message and handled by the routing Error Handler. By default the consumer will use the org.apache.camel.spi.ExceptionHandler to deal with exceptions, that will be logged at WARN or ERROR level and ignored. |
false |
Boolean |
camel.component.twilio.configuration |
To use the shared configuration. The option is a org.apache.camel.component.twilio.TwilioConfiguration type. |
TwilioConfiguration |
|
camel.component.twilio.enabled |
Whether to enable auto configuration of the twilio component. This is enabled by default. |
Boolean |
|
camel.component.twilio.lazy-start-producer |
Whether the producer should be started lazy (on the first message). By starting lazy you can use this to allow CamelContext and routes to startup in situations where a producer may otherwise fail during starting and cause the route to fail being started. By deferring this startup to be lazy then the startup failure can be handled during routing messages via Camel’s routing error handlers. Beware that when the first message is processed then creating and starting the producer may take a little time and prolong the total processing time of the processing. |
false |
Boolean |
camel.component.twilio.password |
Auth token for the account. |
String |
|
camel.component.twilio.rest-client |
To use the shared REST client. The option is a com.twilio.http.TwilioRestClient type. |
TwilioRestClient |
|
camel.component.twilio.username |
The account to use. |
String |