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 xml-rpc - Keap Developer Portal, we does not have field available for order id, shipping details, billing details, can you please help me out with this.
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.
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:
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.
@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.
@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. Keap REST API
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 xml-rpc - Keap Developer Portal 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 xml-rpc - Keap Developer Portal
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 xml-rpc - Keap Developer Portal 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 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: