Method Community

Hello,

I'm trying to use MethodAPIGetScreenURLV2 call to generate a MethodCRM URL to view a specific contact.

I'm having difficulty with the call.  I can get it to successfully send the call, however, it either fails due to TabLinkName & TabName not being valid or in the one case I've gotten it to work (based on examples i've seen online) and return an actual success response, the URL has been empty.

Can someone please help me with this.  My task should be fairly simple.  All I want to do is be able to generate a method URL that will open to a specific contact record in the viewing state.

My problem is, I have no idea what exactly to put for the TabLinkName and TabName parameters.  I have no idea where to find them.  The one video I found seems to deal with the "Classic" version of method since the interface is completely different.

So again - if someone could help me with what the exact parameter values for strTabLinkName and strTabName should be to open a contact record in the "view" state - that would be greatly appreciated!

Thank you!

Devon

Hello Devon,

Thank you.

How about MethodAPIGetScreenURLV3 or MethodAPIGetScreenURLV4? Do those work to generate a URL for the new version of method?

The version 3 and version 4 of the call also have TabName and TabLinkName parameters... And those parameters appear to be the only way to tell the system what screen your trying to get a URL for.

I've listed my use case in the post, basically just trying to get a URL for the view screen of a contact. How would I do that ? Is the getURL function still supported? I know there is v3 and v4, but again both of those still have TabName and TabLinkName parameters so I'm a bit confused.

Please let me know how I can accomplish getting a URL for an individual contact.

Thanks!

Unfortunately, V3 and V4 endpoints will not solve your use case either. We are working on building our REST API and I have added this as a feature request. However, for time being your use case can be solved by a combination of Method customization and API calls. Here is a possible workflow,

Step 1 - Create a new field in the contacts table that will save your URL from Step 2.

Step 2 - Use Method's "Create Short Method URL" action in our action engine and generate URLs for the contacts you need for your use case.

Step 3 - Save URL generated in Step 2 into the field you created in Step 1 using Method's "Update Fields in Table" action.

Step 4 - Now you can retrieve the value of the field saved in Step 3 through API and use it for your workflow. 

If you are not familiar with Method customization I'd recommend working with a member of our Professional Services team. They can help you set this up.

Are you kidding me??!!

What is the point of the GetScreenURL function? Why is this like pulling teeth?

Is this possible or not? 

KILL YOUR DOCUMENTATION IF IT DOESN"T WORK!!!!

I cannot express how frustrating it is that you have information out there that CANNOT possibly work.

I agree,

It was a nightmare working with this.  The documentation was horrible and then having API calls that are avaiable with abousolutely no documentation was unreal... I honestly couldnt believe it - coming from an established CRM company - this is completely unacceptable.

And the task that we were trying to perform was a very common one, it shouldn't have been such a task to get it to work.

I like the CRM - in most other aspects it was very good - but the API and it's related support needs much work.  You cannot have undocumented API calls, its unacceptable.  That makes the API call completely useless.  And asking a developer to completely guess at (several!!) open-text parameter values is completely unacceptable, as our chances of guessing the correct values that your system is expecting is almost 0%.  If you have a parameter that is expecting a certain value - you MUST LIST ALL VALUES THAT PARAMETER IS EXPECTING IN THE DOCUMENTATION - you cannot tell the developer to just guess!!! Thats insane!!

I will never take a job that deals with the methodCRM API again - it was a complete nightmare.  My best wishes to any other developers who venture to work with this api... good luck!

PS - You cannot try to charge companies for support of your API when your documentation is incompleted and call it extra development work.  It's not extra - its just making up for the fact that you were lazy in the first place and didnt document your API correctly, and then when a developer needs to use said API calls, you cannot then charge them for asking questions because there is no documentation.  Thats a great way to lose customers and developers.

I hope you guys change this problem quickly - because otherwise your system was very good.  I liked working with it other than the API.  If you cannot document it correctly - then kill it until you can.  Because otherwise your just hurting yourselves.

Best of luck!

Hello,

Thank you for the feedback. We understand these issues you are facing with our current Soap API and sincerely apologise for this inconvenience. After change in priorities, we are currently working on our REST API and we do plan on solving these problems pretty soon. MethodAPIGetScreenURL endpoints do not work currently. As mentioned in the documentation it also has a very limited functionality in which a user has to be logged into Method in order to use this endpoint. I have created a ticket for our team to update documentation.

DevonBondi,

Thanks for chiming in. I am guessing that the API doesn't get enough use for them to justify putting the resources in. 

Laks,

Thanks for the response. WHY NOT BE EXPLICIT IN THE DOCUMENTAION?

You reference the documenation in your response to my post as if to imply that the documentation makes some reference that I missed! 

I KNOW THAT THE USER HAS TO BE LOGGED IN. This is not my issue at all and I didn't even mention that! My issue was that you don't address  CLASSIC ONLY in your documentation. 

Devon,

Came up with an intersting workaround to get direct page URL's in "New" Method.

Added "ShortURL" field to data tables. (Estimate, Invoice, etc.)
When saving an item (Estimate, Invoice, etc.) I am creating a ShortURL in a Save actionset. I only populate if the field is blank.

This allows me to call a short URL, going directly into "New" Method via the API. It is simply a field in a table.

Maybe this will help someone.