I have a workflow of a payment within a third party.
Because in POS we don't have a way so that the third party could send the response after the user paid in is phone I thought that I could act in the middle of the POS and the third party (red line on the image).
Then we have a another method that the user could check from time to time to see if the response of that exactly request has already an answer.
Can anyone advise me which is the best way to accomplish this? ESB could be used here? Maybe a WebAPI with a logger.
Related
I need to integrate my website to a third party api "getBooks".This API requires JWT token.I use the "getJWT" api to get the token.My question is whether i need to call getJWT api before every call to getBooks api ? Is there a better way to code this problem?
Website description - It does not have a login feature. Customers can browse books and buy any book without login.JWT is only required by third party for their api.
Since apparently you're not reachable for API questions via email, I guess I'd have to put all the questions in here since it would be tedious to create one for each of them.
So we're planning on creating a webhooks system for our integrations to create a better experience for our users. There are a few pieces that are missing for our end to support having a Podio integration that runs 100% on webhooks.
Support organization level webhooks instead at the space level.
Send full object payload in the webhooks push so we don't need to fetch the resource again. Or at least provide a delta of changes.
Have a secret token header that you send with each request so we can assure the authenticity of the data (that it's actually from Podio and it's not someone trying to hack our system).
Github does a great job with this: https://developer.github.com/webhooks/#delivery-headers.
Ability to unsubscribe from a webhook if the client revokes the OAuth credentials. Do you automatically delete that webhook or do we need to contact the user or you guys to get rid of it?
Trello for instance deletes all webhooks associated with a token if it's revoked or a second option is our server sends a 410 Gone back and the webhook, well you guessed it, it's gone.
Do you think something like this is feasible in the near future?
Thanks for your insights :)
Seems pretty valid point. Are there any particular org operations that you are interested to have webhooks for? Can you also describe some use-cases for org level webhooks?
Sending full object payload is pretty complicated because items in Podio can be extremely big and it might be not needed for webhook to get all details. That's why we keep it small and tiny and let Podio partners build own complicated solutions based on webhooks.
Secret token is not much needed if there is only item_id sent in webhook. Let's review it on item modified scenario.
1) User (or anything else) modifies item
2) item.modified webhook is triggered with item_id
3) 3rd party app receives webhook
4) 3rd party app makes a call to Podio API (if it's needed) and gets all required information from Podio API
So, if webhook request is fake, then Podio API will return same item details and nothing is affected. If you want to have some extra layer of security: why not making webhook URL unique and specific to webhook? Then only Podio will know which URL to use to trigger this webhook.
Ability to unsubscribe from a webhook if the client revokes the OAuth credentials.
Sorry, but I don't understand your question. Can you please re-phrase it as new StackOverflow question?
I want to make a desktop application which will need to use a 3rd party REST API to get information. However, the number of requests is limited by the API Key. If I use one API key for all users, the request quota will be exhausted really fast. Now, is it standard (and legal) to make each user sign up for his/her own API key? How are API keys used in context of open-source projects?
To generate the API key, I want to make a sign up form within the application, where the user puts in his/her information and the application sends those information to the 3rd party website to get an API key. Does that sound right?
In general the use of an API is limited to the requests from one machine and not to the API key most of the time.
Again depending of the type of third party services you are using, but the requests to the service should be established by the client not the server.
For example if you want to know geographic coordinates from a specific place, but obviously you can't ask the user directly for GPS coordinates. So you implement the Google Maps Javascript Library into your app which requests the Google API for the coordinates to the human readable address and returns it to the client. This in turn sends the data to your server.
In this way your server never comes into contact with the third party service.
If you have sensitive data or data which shouldn't be manipulated by the user you have to request from your server directly of course. But take a look into the documentation of the service before hack something together which isn't in the intention of the service provider.
Never ever try to outwit a service provider. They will detect your inappropriate use and block you for all time!
Let's say I need to implement a callback service on a website.
I'm curious if it's possible to develop it using Twilio.
For example, if a website visitor provides his mobile phone number from one side, from another side I have a manager using his web CRM application. Is it possible to:
Make a call (using WebRTC?) to a manager
When the manager replies the incoming call, call to the website visitor (on his mobile phone)
Connect both sides together
I know there are lots of ready-to-use callback services, I'm just curious how it works under the hood.
Twilio developer evangelist here.
This is a feature we call Click to Call. Here's how it would work with Twilio:
The visitor provides his number through a form on the site
Generate a call to the manager using the Twilio REST API
When the call connects to the manager, dial the visitor.
This is achieved using TwiML
Whent the call connects, Twilio makes an HTTP request to a URL you provide in step 2
That URL needs to respond with TwiML, which is a subset of XML to tell Twilio what to do with the call
In this case the TwiML would be to <Dial> the visitors number
When the visitor answers the two are connected
This is a high level view of it, we also have a tutorial walking you through Click to Call with Twilio (this is the Python version, but there are others available too) which I recommend you take a look at.
Let me know if this helps at all.
I created an application in VB.net that ties into a scheduling software. It keeps our employees up to date by sending them SMS updates. Employees can reply back to us. Sending messages works great. The application uses the Rest API to connect to Twilio. I can also get a list of incoming messages but I can't seem to get it in a way that works well for me.
Currently my application checks if there are new messages every 5 minutes. The application gets the messages list (with filter DateSent>=today) and then loops through the messages and copies the new ones into our scheduling database.
Is it possible to do a more efficient data pull for new SMS messages using VB.net only? Can I include a time filter in addition to current filter DateSent>=today to limit the result set? Any suggestions? (I don't do web coding unfortunately) Thanks.
Twilio evangelist here.
The best way to do this is just to use Twilios web hook to let Twilio proactively tell you each time its received a message. Whats a web hook you ask? Great question.
A webhook is simply an HTTP request that Twilio will make as soon as it received an inbound SMS messages to your Twilio phone number. You normally tell Twilio to make this HTTP request to a URL that you've created and published to a public website, which you can set up easily by using something like ASP.NET. In this scenario you can think of Twilio like a web browser that is making a request to a web application that you have created.
You can tell Twilio what URL it should request by opening the Numbers tab in your Twilio dashboard, and then locating and clicking the phone number you want to configure:
Now you set the URL you want Twilio to request in the Message Request URL field and click Save:
Now when Twilio requests this URL its going to pass a bunch of parameters with its request that you can use in your application logic. You can also do things like return TwiML back to Twilio in response to its HTTP request that tell it to do things like send an SMS right back to the person who just sent one to you.
If you're looking for a bit more of a step by step, the Quickstarts on our website are pretty easy to follow and will walk you through both sending an receiving text messages. The samples are in C# but are pretty straight forward so converting to VB.NET should be easy.
Hope that helps.
I am doing something similar with VB.Net and Twilio. My solution was to put up an Azure web site and an Azure SQL Database (the two can talk to each other). I set up my Twlio to call an .ashx asp.net web page on my Azure web site. Inside of that web page I have code that reads the incoming text message and saves it to my Azure SQL Database.
Works great, but my problem is the Azure database is in "the cloud" and my app\database that sends the original SMS is on mylocal network. Not sure how to cross that divide... (I should add that my local app can read the Azure SQL database, but seems ugly to have to call out to the Azure to get data. Would have preferred to have just saved it in my local db to begin with.)
Probably not a very helpful post, but maybe give you some architectural ideas. If you want to see my .ashx page just let me know.