Hello Clickatell Support
We are a customer of yours in Australia and have been unable to get any response from support regarding cases created on the website.
We are in dire need of assistance to send vCard and MMS messages via Clickatell. The documentation is non-existent when it comes to sending these.
Please let us know what we need to send to the API to do this. Or let us know if you can't so we can find a different provider.
I asked Clickatell support and got this response:
The sending of MMS or binary messaging is supported. You would need to know how to construct the message though.
That's it. No documentation on how to send a binary message or any examples. :(
according to my knowledge, Clickatell does not support MMS or VCARD messages.
Related
Disclaimer : I am very new to Azure API Management
Hi Friends,
I have the following requirement to be accomplished -
The user will upload an image from a mobile app as "form-data".
An API will be called through Azure APIM and the image will be stored in Blob.
The call should also invoke a backend API at the same time along with the image which does processing and gives the result back.
Could you please suggest how should I proceed on writing the APIM policy for this. I am aware of handling the image at the API side if it comes as part of JSON data. I am just looking for suggestions on the APIM part or more precisely about how to write the policy if the image is part of form-data.
Any help is appreciated.
Thanks and Regards,
Amit Anand
I am just looking for suggestions on the APIM part or more precisely about how to write the policy if the image is part of form-data.
I have reached out to the APIM team for this scenario and they've confirmed this isn't supported at this time. The recommendation is to use JSON payload and, parse & consume accordingly.
If you feel strongly about this, please consider submitting a feature request on Azure UserVoice for the APIM team to review for the product roadmap.
Refer to this issue.
We have used gRPC-JSON trans-coder to submit JSON request to GRPC. Due to the different 3rd party services, Now I have to find a way to submit SOAP request to the GRPC. Please advise me.
You may want to post a question on https://github.com/envoyproxy/envoy to find out if Envoy supports SOAP at all. If not, probably nobody has looked at mapping SOAP requests to gRPC (with or without Envoy).
I am trying to call a web service with a POST request, but I do not know the name of parameters that should be sent in the request. All I know is the address of the web service. Based on that, how can I find the parameters names?
Thank you for your advice,
Cheers.
For SOAP services you could get the interface from published WSDL. For HTTP based web services (REST), WADL was designed to describe the functionality, but it is not widely used, and it is not standarized by W3C.
Therefore, if you are not using SOAP, I suggest to look at documentation
I am trying to receive MMS through my client's messaging app that's in development. One major issue that I am facing is that I am unable to test in India as service providers here are using legacy system of sending MMS. What I mean is while using default messaging app, when I send MMS from one phone to another, I don't receive the message itself, instead I get the link to portal of my service provider, where I have to login with my username and password to see the attachment as well as the text message. Therefore, I am unable to test MMS receiving and the parsing of received binary data on my phone. So, I have to ask if anyone else who has worked on a messaging app before, could provide some guidance on the topic.
I am an android application developer (trying to be one) and I want to learn how to communicate with web sites from my applications. However, I don't know where to start. Can you point me in the right direction?
PS : I believe "web communcation standarts" is wrong term but i don't know how to call them.
I'd suggest that you learn by doing. Pick an idea - let's say you want to upload a picture from your Android phone to facebook.
Now go and research how to do that. Facebook exposes what they call the "Graph API" for all fb resources, including users, statuses, and photos, among other things. The Graph API is a REST API - in other words each item on the backend is modelled as a "resource" which is accessible from a URL. (Learn more about REST on wikipedia). Send a GET HTTP message to the given URL and you can get information on the resource. Send a POST to the container of that resource, and you can add another of whatever it is. In this model, to add a photo, you POST to the album URL. Read on FB for how to do that. They call it "publishing".
But reading that doc page you learn that in order to POST you need an authorization token.
Your app needs publish_stream permissions. How do you get that? Keep reading in the FB doc and you'll see a link to the Authentication and authorization guide. That tells you about how to use OAuth 2.0 in Facebook apps.
Your app will send its first feeble message out, and get an error response. Why? You'll want to examine the message. so you google and figure out that you can use an http debugging proxy to help you, something like Fiddler2 for Windows, or Charles for other systems. So you download that, set the proxy on your Android device, and now you can view outgoing HTTP messages and their responses on your PC.
Keep plugging along, learning what you need to accomplish the task in front of you: in this example, posting a photo from an android device to Facebook.
After you reach that goal, you will have learned quite a bit of practical knowledge for this domain of problem. Then you can try a new goal, and work on that.
After a few iterations of this, you will have learned how to learn, which is even better than learning REST or OAuth. If you know how to learn, the sky's the limnit.
Learn about HTTP first. There is far more to HTTP than there first appears. It is a building block for everything on the web.
You will not go wrong by getting very familiar with this http://www.w3.org/Protocols/rfc2616/rfc2616.html