Name
ROCManageRequest Approve or reject numbers in a request, remove numbers from a Pending request or completely cancel a request.
Description
ROCManageRequest allows the controlling Resp Org to approve or reject numbers in a request, allows the submitting Resp Org to remove one or more numbers from a Pending request, or allows an entire request to be canceled. The following are the allowed fields in reqparams:
rocusername The username registered at SMS/800 for ROC requests.
rocpasswd The password associated with the username registered at SMS/800 for ROC requests.
entity The SMS/800 entity for ROC requests.
dnlist A comma-separated list of numbers to be managed in the specified request.
dnlist should not be specified when action is set to 'cancel', as this is the only action that affects the entire request. For all other values of action, dnlist is required.
* action The action to perform on the set of toll-free numbers in this request. Valid values are:

Value Description Allowed By
approved Immediately approve the request for the specified numbers Controlling Resp Org
pendingApprove Approve the request for the specified numbers when the due date of the request is reached Controlling Resp Org
cancelPendingApprove Cancel a pending approval of a request for the specified numbers. This can only be done if a pendingApprove was previously done. Controlling Resp Org
rejected Reject the request for the specified numbers Controlling Resp Org
remove Remove the specified numbers from this request Submitting Resp Org
cancel Cancel an entire request Submitting Resp Org
* txnid The Transaction ID returned from a ROCRetrieveRequests API call.
rejectcode A comma-separated list of codes indicating why these numbers were rejected.
This parameter is required if action is reject.
Valid values are the codes shown in the table below.

Code Description
01 Customer name mismatch/missing
02 Address mismatch/missing (verification done if address is different but all other information is the same)
03 Contact/Customer signature missing
04 Toll-Free Shared or Bundled
05 Customer signature date missing/or expired (must be less than 30 days)
06 Sent to wrong Resp Org
07 Toll-Free Number not listed on request
08 All data mismatch
09 LOA missing or linking Reseller/Subscriber LOA missing
11 Illegible LOA
12 More recent LOA (provide copy of LOA to Resp Org)
15 Unauthorized contact/Customer signature
18 Resp Org is no longer in control of the Toll-Free Number
The above codes and descriptions are taken from the SMS/800 document Centralized Resp Org Change (ROC) Management System Web Services Interface Specification, Issue 1, Version 2.14, dated March 10, 2016, Appendix C - Table 14.
rejectnote A note indicating why this request is being rejected.
Either the single parameter entity or the pair of parameters rocusername and rocpasswd must be specified.
ROC Messages
ROCManageRequest sends a ProcessRespOrgChangeRequest message to approve or reject numbers in a request, a RemoveDialNumbers to remove numbers from a request or a CancelROCRequest message to cancel a complete request.
Results
A RocManageRequest response is an XML document embedded within the normal API response. If the request was to approve or reject a request then a ProcessRespOrgChangeRequest XML document will be embedded; if the document was to remove numbers from a request then a RemoveDialNumbers document will be embedded. Note that the response XML for these two types differs only in the top-level tag, as shown below.
The ErrorList section will only be included if an error has occurred.
A typical XML response for approving or rejecting numbers in a request will have the following fields.
<ProcessRespOrgChangeRequestResponse>
<StatusCode>1</StatusCode>
<ErrorList>
<Error>
<Code>ErrorCode1>/Code>
<Description>ErrorDescription1</Description>
<AdditionalInfo>AdditionalInfo1</AdditionalInfo>
<Error>
<ErrorList>
</ProcessRespOrgChangeRequestResponse>
A typical XML response for removing numbers from a request will have the following fields.
<RemoveDialNumbersResponse>
<StatusCode>1</StatusCode>
<ErrorList>
<Error>
<Code>ErrorCode1</Code>
<Description>ErrorDescription1</Description>
<AdditionalInfo>AdditionalInfo1</AdditionalInfo>
<Error>
<ErrorList>
</RemoveDialNumbersResponse>
A typical XML response for canceling a request will have the following fields.
<CancelRespOrgChangeRequestResponse>
<StatusCode>1</StatusCode>
<ErrorList>
<Error>
<Code>ErrorCode1<Code>
<Description>ErrorDescription1</Description>
<AdditionalInfo>AdditionalInfo1</AdditionalInfo>
</Error>
</ErrorList>
</CancelRespOrgChangeRequestResponse>
Most data validation is left to Somos to perform. In some cases, 8MS may provide some up-front validation. In that event, the following XML will be returned.
<err>
<code>E0000000</code>
<context>param-in-error</context>
<description>text describing error.</description>
<err>
Possible errors returned for this API call include
Code Context Description
E0000089 action Parameter 'action' was not specified
E0000090 action Parameter 'action' is invalid. Must be one of approved, pendingApprove, cancelPendingApprove, rejected, remove or cancel
E0000093 entity/rocusername A valid 'entity' or 'rocusername' must be specified.
E0000095 rejectcode rejectcode(s) are required when action is rejected.
Example
The following request parameters will remove a number from a ROC request:
entity~YH;action~remove;dnlist~8005551212; txnid~~b5fa1b8a-a54c-4c2a-8014-3e5f2dd30d6e;