API to create orders

Hi,

Below is the link for creating manual orders in infusion.

https://help.infusionsoft.com/userguides/sell-online/create-an-order/create-a-manual-order

Can anyone please let me know how to create these orders through API, because in API documentation there are some fields that are missing.

Thanks

Hi @Max_Rubin,

The way you would create an order through the API is by first creating a blank order using InvoiceService.createBlankOrder. Then you would use InvoiceService.addOrderItem to add items to the order. The last step would be to apply a payment either by using InvoiceService.chargeInvoice or InvoiceService.addManualPayment if you are taking payment in an external system.

What are the specific fields that you need that are missing?

Hi,

Thanks for the reply, actually what exactly we are trying to acheive is to import complete order detail which was processed in our external e commerce application.

in https://developer.infusionsoft.com/docs/xml-rpc/#invoice-create-an-invoice, we does not have field available for order id, shipping details, billing details, can you please help me out with this.

Thanks

Hi @Max_Rubin,

In order to set those additional fields, you will need to use DataService.update to update a record in the “Job” table (see Job section in the table schema docs). The “Job” table represents an order and should contain all of the fields you need to update.

@Max_Rubin,

The details you’re mentioning are actually recorded on separate tables and are not created specifically with the order (some of them anyway). The order id cannot be written. It is created as an AUTO_INCREMENT value in the apps database. You can store the original order id in a custom field on the order table if you really need it. Shipping details really don’t exist in Infusionsoft. Shipping address is recorded on Address2Street1, Address2Street2, City2…and so forth but actually shipping data (like what carrier, delivery dates, instructions etc) do not exist, though the products table does contain a few fields (shippable, shipping time and weight). Billing details are similar. Billing address is StreetAddress1, StreetAddress2, City, State etc but the rest will be in a couple of tables (Payment, CreditCard, CCharge, InvoicePayment, PayPlan, PayPlanItem and SubscriptionPlan may all be helpful to look at). The table schema documentation can be found here:

https://developer.infusionsoft.com/docs/table-schema/

Pardon the necro but I don’t want to create a new topic as the context is entirely in your post…

Should I use the flow you outlined for creating subscriptions? Or should I specifically go through the createInvoiceForRecurring first and then I skip the InvoiceService.addOrderItem step and go straight to InvoiceService.chargeInvoice?

The flow for subscriptions is a bit different. First you would need to create a RecurringOrder record using DataService.add. Then you would use InvoiceService.createInvoiceForRecurring which will create an invoice for subscription record. Lastly you would call InvoiceService.chargeInvoice to collect payment on the subscription invoice.

Should I be using the id (integer) that is returned from calling DataService.add against the RecurringOrder table insert in my subsequent calls?

is it the value I should use the subscriptionID field when calling InvoiceService.createInvoiceForRecurring?

@Ray_Farias, apologies for the delayed response but you’re correct that the id that’s returned from creating the RecurringOrder should be used when calling InvoiceService.createInvoiceForRecurring.

Alternatively, you could also use InvoiceService.addRecurringOrder to add the subscription rather than using DataService.add.

@Nicholas_Trecina Hi all, again sorry for the long bump. Now that the REST API is available, is it better to create orders with this, or use the XML RPC one?

Also, is it possible to POST variables like “cost price”? This doesn’t appear in the order endpoint as a parameter but is visible on the response sample. https://developer.infusionsoft.com/docs/rest/#!/E-Commerce/createOrderUsingPOST

InvoiceService.addOrderItem returns Invoice ID . So how can use DataService.update to update a JOB custom fields as it requires OrderId .

You can use DataService to Fetch the Invoice which contains the Job/Order Id. From there you can update the the Job/Order custom fields.

Also InvoiceService.addOrderItem does not return the invoice id, just a boolean of whether or not the operation was successful, but you need to invoice number to call InvoiceService.addOrderItem so you should have the Invoice ID regardless.

we are doing the below :
The way you would create an order through the API is by first creating a blank order using InvoiceService.createBlankOrder. Then you would use InvoiceService.addOrderItem to add items to the order.
The last step would be to apply a payment by using InvoiceService.addManualPayment we are taking payment in an external system.

InvoiceService.createBlankOrder returns the Invoice ID . It does not return OrderID

I assume what you are saying to use https://developer.infusionsoft.com/docs/xml-rpc/#data-query-a-data-table to Query the Invoice Table using the InvoiceId and retrieve the ORDERID . Then use that OrderID to add order custom fields using n Order Table using
https://developer.infusionsoft.com/docs/xml-rpc/#data-update-a-record

Alternatively add Order using PlaceOrder :
https://developer.infusionsoft.com/docs/xml-rpc/#order

This will give OrderID and InvoiceID both . Then using InvoiceID we add Manual payment InvoiceService.addManualPayment
and then using OrderID we Update the Order Table using https://developer.infusionsoft.com/docs/xml-rpc/#data-update-a-record for Order Custom Fields …

please suggest which approach is best and we can use

Also suggest if the same can be achieved better using REST API or we use XML-RPC API only

This is exactly what I am saying

This is doable as well. You just have a little less control over what the order looks like versus creating a blank order then building it up.

As far as using REST vs XML/RPC, I would lean for REST. XML/RPC has been deprecated and all new API efforts are being put into REST. You can achieve the same result with REST using: