Migrating From the SOAP API

SOAP Example

Replacing a product in a subscription requires two SOAP calls. The first SOAP call removes a product from the subscription. The second SOAP call adds a different product to the subscription.

<api:amend>
   <api:requests>
      <api:Amendments>
         <obj:ContractEffectiveDate>2017-03-01</obj:ContractEffectiveDate>
         <obj:CustomerAcceptanceDate>2017-03-01</obj:CustomerAcceptanceDate>
         <obj:Description>Removing a product</obj:Description>
         <obj:EffectiveDate>2017-03-01</obj:EffectiveDate>
         <obj:Name>Removing a product</obj:Name>
         <obj:RatePlanData>
            <api:RatePlan>
               <obj:AmendmentSubscriptionRatePlanId>8a8081085e0d4b70015e4b844495058d
               </obj:AmendmentSubscriptionRatePlanId>
            </api:RatePlan>
         </obj:RatePlanData>
         <obj:ServiceActivationDate>2017-03-01</obj:ServiceActivationDate>
         <obj:Status>Completed</obj:Status>
         <obj:SubscriptionId>8a8081085e0d4b70015e4b8444810589</obj:SubscriptionId>
         <obj:Type>RemoveProduct</obj:Type>
      </api:Amendments>
      <api:AmendOptions>
         <api:GenerateInvoice>false</api:GenerateInvoice>
         <api:ProcessPayments>false</api:ProcessPayments>
      </api:AmendOptions>
      <api:PreviewOptions>
         <api:EnablePreviewMode>true</api:EnablePreviewMode>
      </api:PreviewOptions>
   </api:requests>
</api:amend>

<ns1:amend>
   <ns1:requests>
      <ns1:Amendments>
         <ns2:ContractEffectiveDate>2017-03-01</ns2:ContractEffectiveDate>
         <ns2:CustomerAcceptanceDate>2017-03-01</ns2:CustomerAcceptanceDate> 
         <ns2:EffectiveDate>2017-03-01</ns2:EffectiveDate>
         <ns2:Name>Add a product</ns2:Name>
         <ns2:RatePlanData>
            <ns1:RatePlan>
              <ns2:ProductRatePlanId>8a8081085d834928015d9ce60ef41acf</ns2:ProductRatePlanId>
            </ns1:RatePlan>
            <ns1:RatePlanChargeData>
              <ns1:RatePlanCharge>                      
                 <ns2:ProductRatePlanChargeId>8a8081085d834928015d9ce6ae821ad1</ns2:ProductRatePlanChargeId>                      
                 <ns2:Quantity>20</ns2:Quantity>                  
              </ns1:RatePlanCharge>                                           
            </ns1:RatePlanChargeData>
         </ns2:RatePlanData>
         <ns2:ServiceActivationDate>2017-03-01</ns2:ServiceActivationDate>
         <ns2:Status>Completed</ns2:Status>
         <ns2:SubscriptionId>8a8081085e0d4b70015e4b8444810589</ns2:SubscriptionId>
         <ns2:Type>NewProduct</ns2:Type>
      </ns1:Amendments>     
         <ns1:AmendOptions>
            <ns1:GenerateInvoice>false</ns1:GenerateInvoice>
            <ns1:ProcessPayments>false</ns1:ProcessPayments>
         </ns1:AmendOptions>        
         <ns1:PreviewOptions>
            <ns1:EnablePreviewMode>False</ns1:EnablePreviewMode>
         </ns1:PreviewOptions>
   </ns1:requests>
</ns1:amend>

Migration Notes

• You only need to make one call using the REST API.
• Specify account numbers instead of account IDs.
• Specify subscription numbers instead of subscription IDs.
• The effective date specified in the SOAP EffectiveDate field corresponds to the contract effective date of the order actions in the REST API.
• You do not need to specify the status of the amendment in the REST API. Because the amendment will be in the Complete status if the call succeeds. You cannot create draft amendments in Orders.
• To generate invoices and collect payments, specify the runBilling and collectPayment fields instead of the GenerateInvoice and ProcessPayments SOAP fields.
• Currently, we do not support specifying the name and description of order actions (the corresponding Name and Description SOAP fields).