How do I get a callback url? - facebook-apps

I am creating my first chatbot with Facebook for developers and I don't know how to set a callback url. I already have my url (IP address of my EC2 instance). Do you know by any chance how could I obtain one? And do I have to set a domain name for my app? Thanks a lot in advance!

Yes, you need a domain name. The Platform won't accept an IP address for a webhook. All you need to do is expose an https endpoint on your EC2 instance that can accept POST requests, and provide that URL.

Related

How do I get the website subdomain url that calls my API?

I have A.Mysite.com and B.Mysite.com all calling my API.
Is there a way for my API to know where the request came from? (A.Mysite.com vs B.Mysite.com)
Thank you.
If you have control over the two sites calling the API, you can configure the two to send an additional parameter to identify themselves, and use this to track them. You would need to modify the API to accept this additional parameter. This is the ideal solution.
Additionally, there are numerous http parameters that may be used to track the origin of a http request. If the two callers use two different static ip addresses, this would probably be the most reliable method. For example, if the API is written in PHP you could access the remote IP address using $_SERVER['REMOTE_ADDR'].
The domain/subdomain of a website is only used during DNS resolution, when you try to send to the domain. Each domain will always send as it's ip address. If they both originate from the same ip address, they will be indistinguishable unless you add an identifying parameter.

Forwarding API calls from a sub dominos to static IP address(from ISP)

I currently have an API setup at
http://public_static_IP:5000/api/parameters (POST requests).
I have bought a domain from NameCheap and hosted in GoDaddy, also added SSL from Cloudflare.
I have created a URL Redirect of a subdomain(http://www.web.domain.com) to http://public_static_IP:5000, which is a webpage and it is working fine.
I did the same with another subdomain(http://www.api.domain.com) to API endpoint which is an only POST request, so when I add all parameters and send a post request to this subdomain it is giving Method not allowed.
This is very important for us as users will always be using this API service and we don't want any downtime(sometimes ISP will be down), if ISP is down we want to temporarily route to some cloud service(AWS or Google Cloud) without asking users to change their base URL always.
Thanks in advance.

Podio webhook IP address?

Looking to whitelist the IP address for webhooks. I'm implementing some automations using the PHP SDK for a client, but their server isn't accessible via HTTP unless we whitelist the specific IP address of origin. Where do those posts originate from?
Thanks!
As Podio is built on a scaleable infrastructure we continuously add more capacity to our background worker cluster. This means that we cannot guarantee which IP addresses we will connect from when doing a webhook.

How do I go about setting up SSL for my API and my Web Client in a Azure Cloud Service?

I have 2 web roles in a cloud service; my API and my Web Client. Im trying to setup SSL for both. My question is, do I need two SSL certificates? Do I need 2 domain names?
The endpoint for my api is my.ip.add.ress. The endpoint for my webclient is my.ip.add.ress:8080.
Im not sure how to add the dns entrees for this as there is nowhere for me to input the port number (which I have learned is because its out of the scope of the dns system).
What am I not understanding? This seems to be a pretty standard scenario with Azure Cloud Services (it is set up this way in the example project in this tutorial, for instance http://msdn.microsoft.com/en-us/library/dn735914.aspx) but I can't find anywhere that explains explicitly how to handle this scenario.
First, you are right about DNS not handling port number. For your case, you can simply use one SSL certificate for both endpoints and make the two endpoints have the same domain name. Based on which port is used by user request, the request will be routed to the correct endpoint (API vs. Web Client). Like you said this is a relative common scenario. There is no need to complicate things.
Let's assume you have one domain www.dm.com pointing to the ip address. To access your Web API, your users need to hit https://www.dm.com, without port number which defaults to 443. To access your web client, your users need to hit https://www.dm.com:8080. If you want users to use default port 443 for both web api and web client, you need to create two cloud services instead of one, then web api on one cloud service and web client on the other cloud service. Billing wise, you will be charged the same as one cloud service.
Are there any reasons you want to make 2 different domains and in turn 2 SSL certificates? If so, it is still possible. Based on your requirements, you may have to add extra logic to block requests from the other domain.

Are Shared hosting IP OK for Mandrill API Requests?

Are Shared hosting IP OK for Mandrill API Requests?
I'm trying figure out if a Nightmare is true or simply pure work overload. :)
Mandrill comes with a Shared and Dedicated IP Options for sending out emails. What I fully 100% agree with. But do I need a Dedicated IP for sending out API Requests to Mandrill? Or can Shared Hosting IP work as a starting point. (e.g Bluehost / Hostgator Shared Plans ).
Is there a possibility, that tow Account will use the same IP and lead to very Angry Mandrill? :{
I am planing to apply for a Dedicated IP. But would like to not rush with buy every feature to quickly.
The Mandrill dedicated IP option is an IP that is only used for sending your emails. You don't make API calls to that address. You would still make API calls to the same API endpoint described in the Mandrill API docs - with a dedicated IP, once we receive and process your mail, we would then route it over a dedicated IP address instead of the shared pool of sending IP addresses. All of the sending IPs are only used for sending emails. They aren't used for other portions of the application or API.