We are exploring how to call Availity's API to for EDI files such as 278i. Availity has a very simple API example which doesn't specify any EDI transactions. I was able to get the simple demo working (authentication, token, client retrieval) but still clueless about how to do the EDI calls.
I have sent a support ticket to customer service but they replied saying we should have the "view". I'm not sure what that means.
So my question should be, is there some documents/examples for API calls to Availity for EDI transactions? Or if you happen to have non-Availity documents that can be a good reference too.
Thank you for your time.
Related
What is the recommended way of detecting if a store has CarrierService API available? I.e. it's on the right plan or billed annually.
I noticed attempting to retrieve a list of carrier services could work since it's always empty if a shop cannot use the CarrierService API. However, that feels hacky. Apart from that, I can imagine a scenario when this can return empty also for shops with that API available. Is there a better, more reliable way?
The only sure way is to try creating a carrier service. This API call will fail with a specific error message in the response body when the shop doesn't have that feature.
Is it possible to make a call from advanced workflow to the Archer API? I'd like to avoid making a custom object and didn't know if I could somehow otherwise initiate a call.
No, you can't call Archer API from Advanced Workflow functionality.
Any data related manipulation can be done with a data feed. And where "Archer to Archer" data feed can't deliver "SQL" type data feed will. SQL data feeds targeting Archer Instance database can do magic if you are willing to document them and test them with every Archer upgrade.
I had to use Archer API only in very complex integration cases. In these cases API code was running on the application server as a service. I think that invoking API calls via JavaScript from end user's browser can be considered a bad practice.
I am building a RESTful api for a project at the moment, the API will used for a web application, a mobile application and maybe eventually a desktop application.
There are a few instances where emails need to be sent to notify the user of an event that has happened within the application. What I am not sure of is where to does a an APIs job finish, should the API be responsible for sending the emails, or should the application send the emails based on what response comes from the API?
Basically what I am asking is where does an APIs job start and finish, is an APIs job just getting date from point A to point B? Or can it deeper capabilities?
It's a common mistake that many developers are still making. An API is just an interface through which you expose your underlying system to be accessed by other systems. How you expose your system depends on what functionalities you want to be visible to the external world. Moreover, your business logic should be entirely on your backend rather than spread over your mobile/web applications.
Having said that, my answer is yes! Don't think of it as "my API is sending emails". Think of it as "my MAIN SYSTEM is sending emails". Whether you want to expose this email functionality through your API or not is another completely different thing.
Rest confuses me sometimes. I know that it involves creating an API layer over your data and then you make calls to that data through the API. The best way I think of Rest is that the actual Twitter website interfaces with the data-layer through API calls.
That made me wonder then: Is a backend-service like Parse also a Rest API to your data?
What might be the difference between Parse and say, building your own Rest API like this guy did: http://coenraets.org/blog/2012/10/nodecellar-sample-application-with-backbone-js-twitter-bootstrap-node-js-express-and-mongodb/ (he's getting some solid google rankings for his API tutorials).
A simple yes/no might answer the question, but providing details will really be appreciated.
I look forward to the answers.
Parse is built around a restful API just like most, if not all, other mBaaS out there.
A RESTful Api isn't just CRUD operations though nor is it the same thing as Parse. Parse is a company that provides a remote backend to developers using a RESTful api.
RESTful api !== BaaS
I have dealt with about 5 mBaaS and Parse isn't really one of them, but I've glanced at their API reference for JS and I think they use mongodb clusters. An mBaaS usually provides the developer the ability to have cloud storage, push notifications, server side code, easier social media integration, and mobile analytics. So it's not just any backend. Although there are some mBaaS, like Urban Airship, that only supply push notifications to developers.
A RESTful api at it's core usually has some key functions that are centered/wrapped around an httpRequest
They usually use "GET", "POST", "DELETE", and "PUT" to make all calls. Some allow the implementation of rpc for custom server logic. An mBaaS takes a lot of work to implement right and well. You can't build Parse in a Day. It takes a lot of planning and such. The differences between Parse and that guy in link are in the implementation, range of features, and purpose in general(the audience).
To better understand REST maybe look here you can also read the HTTP spec if you are feeling adventurous.
I have read a thread regarding Yodlee implementation and on one of the responses a user said "It is easy to intergrate your app with Yodlee API" How exactly is it easy to implement Yodlee and integrate it with an existing C# Web App? I don't mind getting dirty, but I would like to know how hard can it get and is there forums out there and enough developer support? Please assist urgently as we need to test and implement Yodlee before the end of the month also note I am new to Yodlee and API integration.
Thanx in advance
You may not need to get dirty at all. It is so simple to implement Yodlee in any .net language. Yodlee provide a client library for .net as well, all you need to do is to wrap your business logic around the library. On other hand if you wish to take greater control of api calling as well, you will be provided wsdl proxies to the web services, code what ever way you feel good with it.