CRM APIs - what's missing?

Hi Cristinel,

I posted on this forum a couple of days ago regarding Contact_SecureZoneListUpdateInsert. I'm struggling to get it to work, as it needs to use email as a record's identifier. If I use Contact_RetrieveByEmailAddress I find that the 'emailAddress' field of all records is empty, and the email address is instead stored in 'PhoneNo=>PhoneNoTypeID=>7'. I suspect that Contact_SecureZoneListUpdateInsert is trying to match the email address I enter with the 'emailAddress' field rather than 'PhoneNo=>PhoneNoTypeID=>7'. Any ideas on that?

I suspect that this isn't working elsewhere also, but I haven't tested that theory. I feel it'd be more useful to use entityId or externalId as the identifiers as these are less likely to change, and are present in every CRM record.

Thanks,

I use the SOAP API both server side and client side (Javascript SOAP).

Currently missing:

- A JSON API

- File API, move files, delete files, edit, change, including moving to secure zones.

- Shipping API, for existing built in shipping, I understand you can do a custom shipping amount.

- Get orders or anything within a date range.

more as I think of them.

- JSON output has already been announce

- File API already exists

The latter two are good points but BC are looking for more of what data is not being output yet TheBCMan so when they do the REST version of the SOAP api they are exposing the right information. Shipping is not CRM it is eCommerce and what your asking is the needed complete rebuild of that BC feature. BC wont be looking to do that yet.

Orders as well would be the eCommerce and they are asking about CRM here.

Liam please don't flame other users for posting an answer, you seem to like to bully / talk down to anyone giving a second opinion, especially from my posts, I understand your trying to help and make sure people get the correct info, but you're going about it wrong and it can't be helping your business.

The file API is not part of the SOAP XML API (see original question) and the smile face indicated a joke.

Hey,

No I do not

BC have already announced the sorting of API's, asking people what they are looking for and having REST versions of the SOAP API.

It would be pretty silly to re-do the file end points they have already which also has bcpi.js and go backwards to make them into REST. It is also not what was asked here as they asking about CRM.

BC have a number of months ago asked people to comment on missing tags etc so they can work on filling in the gaps from existing data and also will be looking to expose, and same with the API. Matt's post is a perfect example of that.

This is all out there, I am sorry if you not put yourself across them and I am not bullying, it is not my fault if your not aware of features and things that exist in BC and if you do not know and someone points these out for you - It is good info, not bullying.

You are not wrong about shipping and a few years ago BC discussed with partners how their ideal would be an xml or maybe now it would be JSON based file you could submit to be able to implement newer shipping options but it is a bit of work and not above other priorities, and an API would be handy to. So your not wrong in wanting that, but in terms of what BC has announced they are doing, and in this thread what they after. It's not what they are after.

Hopefully this helps you with the picture of what is happening with BC a bit more to enable you to provide things like "This field is missing" And if you check out the BC reference documentation, on the Endpoints you see me and others documenting what is missing, what actually outputs in the API compared to what is documented it should etc. I mean things like asking for file API when there is file API, that is not me bullying or anything, I do not understand why you would ask for it when it exists.

I would like to see these added to the CRM API:

• Email campaigns have been sent to a contact
• Trigger an email campaign to be sent to a contact (We are seeing a huge increase in marketing segmentation)
• Campaign List retrieval of a contact (as far as I am aware there is only an update endpoint?)
• Contact Activity Feed

I would like too add to the list

- Ability to update (pre) orders via order ID only. currently you need an entity ID to update an order, which is stupid because you can not update shopping carts for non logged in users, which is the basis of any e-commerce system. BC is obviously able to do it please extend that to the API.

TheBCMan - Find out about the stuff BC revealed at Max. You will be happy.

Link?

Hi TheBCMan,

Take a look on the following links:

http://docs.businesscatalyst.com/developers#!/beta/api-v3-sorting-filtering-and-partial-re presentation-methods

Developer reference

In developer reference, take a look at CRM API v3. Nevertheless many exiciting things can be achieved through module_webresource (aka magic / godmode). Take a look at unconference record for finding out more details and getting more information about new APIs.

Kind regards,

Radu

Since there is no order ID on the update order function in API v3 does that mean you don't need entity ID to update, the sample code would leave me to believe that would be possible and it would automatically use the session ID?

When is this live? I'm also assuming this works on the front end as well? or are we still limited to the admin area?

No, this is still for admins because of security reasons.

I think it's better not to change any ids at all.

There will be a new module that can consume the API data and liquid can render the results TheBCMan

Liam: When?

It is already in production. We will put up documentation for it in the next couple of weeks. Meanwhile, we will publish the MAX 2014 samples from unconference and official BC sessions. They should provide a good starting point for using the new module together with liquid.

Thanks Radu, can you provide any insights on whether the suggestions I made earlier will be considered.

We will definitely analyse your suggestions as they make perfect sense. Thanks for your input Dale.

I would say give all the stuff ago, You will likely find you may not need the things directly as what you have could be enough. I see a few things on here already that you can do now with the things the guys have done.

Access to order "details" field when creating, editing or getting item details via API v3.

Can't find this field in documentation: Developer reference

It seems to be missing.

At the moment is called shippingInstructions. It might be renamed in the future but for now is shippingInstructions. Is it ok?

Yep, thanks.

Just to re-iterate on that so what Radu said is clear - It is already accessible as shippingInstructions.

Who's idea was liquid? It's got to be the worst choice out there, sure it's used with shopify and I understand it might pull some customers over from there but I don't want to put logic into a HTML file, logic is the javascript, there should be NO logic in the HTML template!

Liquid is simple and limiting, perhaps that is what you are going for? I'm not sure.... I wont be using it unless there is a gun to my back... better to ajax call to the BC JSON outputs and use handlebars or mustache to render templates once things are finalized.

How do I get into the inner BC circle to voice concerns?

You're going to be a lone voice, I bet.

Liquid is the single greatest thing BC has implemented. The speed of writing liquid logic compared to JS callbacks and AJAXing is a million times faster. I've been using jQuery and AJAX calling for over 6 years with BC now, and I can tell you that after 1 week of using liquid, and collections, I can do what used to take me about 2 hours in about 10mins now.

...And suggesting that using JS for a templating engine compared to server side... you've just lost the plot. Think of the SEO benefits of liquid. And performance enhancements with server side scripting.

Sorry mate, you're a lone voice in this.

Stephen,

Liquid vs (existing BC), yes million times better... agreed.... Liquid vs other systems like handlebars or mustache, not in my opinion, BC needs to look at what facebook are doing with their apps and SDK's to see what is possible. You can write SQL queries directly in javascript and query facebook's databases directly... my point is from a developers point of view logic should not be in the HTML template. You should separate logic and templates....

It wont (I hope) be a issue anyway since I believe JSON API outputs are coming

Hi mates, Having APIs access from front-pages would be the great alternative to Liquid. If you want better SEO, use Liquid. If you want more complex data works in your application, it would be great to use APIs. So his voice is not alone ))

Can Liquid load data without page reload?

Sorry TheBCMan, but you really are going to be the lone voice on this one.

Handlebars - Mustache... are Javascript, not server side, Liquid is server side. And they are all Templating Syntax and where you use them is in your markup, the first few examples on any of those shows this.

Do you know what they all call themselves?

Templating syntax - And they go into the BC templates. I do not understand why you would hate it.\

This would only be an issue if sites are built incorectly and pages having liquid markup etc. This should not be the case.

Liquid simple and limiting?

That is a really confusing statement - Because far from that, I think you need to look at it and learn it more.

I think it is a crazy statement to use a javascript render and json data which will be slower and still have markup and template calls, inline.... Eeeek, ok for apps but on a website... Crazy.

Quote from Handlebars site:

Handlebars provides the power necessary to let you build semantic templateseffectively with no frustration.

You also need to look at what BC are doing.

Liquid is SERVER SIDE!

Secondly it access more data from BC then the BC tags.

Thirdly BC have already shown of {module_webresource which can access the API on the front end.

I think you guys just need to spend some more time reading about this stuff and what BC has announced.

Thanks, can you provide a link to the {module_webresource} reference or any kind of information?

This is the problem, BC is only listening to a certain group of people, javascript page rendering is not slower... it is faster to the client!

Instead of using the webserver CPU you are using the CPU / GPU of the client to make the page, you (the client) basically says, give me the template, give me the data and give me the instructions how to put it together (all in parallel) and you hand it off to the client. As apposed to the webserver doing all that for you (which takes time)...

SEO concerns; search engines index rendered pages not HTML source code, otherwise it would be very easy to keyword stuff and display something totally different.

I'll take liquid over previous stuff BC has offered but BC is needing a complete JSON API so we can actually do modern ways of coding including mobile apps and other things.

I will just say I and others will disagree on that, and I think the majority view is this all is not just good but great stuff, And this may be the thing that moves you off BC if you do not like it because it is here to stay and its a good thing.

If you want to continue to use what your doing and use the JSON stuff on BC feel free to do so.

I'll take something over nothing... not going anywhere sorry Liam

BC Unconference at MAX 2014

Radu shows it off here

Developers

This is the key for the module to access the data.

The guys are working on documentation on this for us all to try etc.

Hi TheBCMan,

BC provides backend apis and a way to these APIs in frontend (module_webresource). With this you can create your own apis for your site where you control the data you want to expose. Here is a simple use case which can be achieved with what we currently have in production:

I want to create a sign up form where user must choose a username and a password. As a constraint, I want to keep username unique within my site and I want to be able to check through AJAX if a given username value is reserved or not. The strategy for achieving this is presented below:

1. Create a page on your site (e.g /max-2014/backend/check-username-uniqueness.html with the following code in it):

{module_webresource resource="customers" version="v3" where="\{'username': {{this.globals.get.username}}\}" fields="id" collection="customers" template="" skip="0" limit="1"}

2. From your browser access the follow url: http://<site-domain>/max-2014/backend/check-username-uniqueness.html?json=true&username=bcman. Once you did this you will get a valid json object which contain customers as key. customers.totalItemsCount tells you how many customers already have bcman username.

3. Write your client side code and use this API through ajax.

               var username = "bcman";

                var response = $.ajax({

                    "url": "/max-2014/backend/check-username-uniqueness.html?username=" + username + "&json=true",

                    "type": "GET"

                });

                response.done(function(data) {

                    if(data.customers.totalItemsCount == 0) {

                         console.log("username available");

                         return;

                    }

                    var customer = data.customers.items[0];

                    console.log("Username is taken by user with id: " + customer.id);

                });

Early next week we will publish several how to tutorials on our documentation covering module_webresource.

Please let me know what you think. You might also find useful another discussion from forum: Web App API and front-end pages

Regards,

Radu

Radu,

Thanks for the reply and the info, yes I knew about this, this is exactly how I will use a javascript templating system as I previously discussed, I am actually already do this on some sites minus the JSON and using text searching to grab the info or parts I need but there is alot of wasted resourses doing that obviously.

After the constant changes with the BC Apps I was waiting until everything was final to take a look, when is all this live? now?

I think if you made the name change asap Cristinel on module_webresource I think that would be good, People can start to trial it a bit more etc when you put up documentation and then you wont have many bigger changes.

You got to ask again but I think everyone would be fine with {module_resource - Because it would not limit you to what you may expose it. {module_data is the other floated but I think thats not as expansive.

Are you just porting the current API to JSON or are you opening up / allowing new API access to shipping, gift cards, discount codes, the live shopping cart, webapps ?