In this use case let's assume that you are building an app to enable users to send faxes. The document that a user wishes to fax would either have been prepared beforehand and stored on the file system (for example, a Microsoft Word document), or could be created through an online editor (in which case the resulting document would most likely be HTML).
The user is presented with a web form to either upload or edit his document and to enter a destination fax number (your application may possibly provide an address book from which the user can select one or more recipients).
Your app would submit the fax to InterFAX by calling one of our outbound “send fax” methods (depending on which API you use).. There is no need to retain the state(s) of the user's fax(es) if you submit the fax using the user's unique InterFAX credentials. This is different from using InterFAX for production faxing, there is no need to locally retain the id of the submitted fax.
Once the fax is submitted, InterFAX gets busy preparing it and sending it out. This may take a few minutes. Should the client become interested in seeing the status of his fax (succeeded/failed), your app would call InterFAX with one of our “get status” methods. This returns a structure detailing the most recent faxes. Of course, you could request more or fewer faxes by using the limit parameter. Simply format and display the returned values or a subset to the user.
The diagram below shows the sequence of events.
Note that hardly any business logic is required in this app, as InterFAX does everything for you. All you need is a simple form to accept fax content, and thereafter some presentation logic. The important thing here is to use the user's credentials to be able to keep different users' activities separate. InterFAX supports this by allowing multiple users under a single account (contact us to set this up).