Features & Pricing

Each feature presented below requires that you create an account.

How do I create an account?

In order to create an account, you must provide personal information (firstname, lastname and a valid email address) and general identification informations (username and password).

If you wish, you can create an account right now.

Do I have to pay to have an account?

No. You can create a Free account. This type of account lets you access to the features without having to pay each month. At least you'll have to buy credits for the feature(s) you need.

What is the interest to create an account?

As soon as you have an account, you can upgrade it in order to be able to fully use all the features. Otherwise, you can simply purchase credits.

You are free to close your account at any time because you are not engaged. When you subscribe a not-free account type, you pay each month for the coming month.

What should I know about the features?

All the features are attached to private packages. As soon as you know how to create a private package, you know the basics.

Moreover, when you have a private package, you have all what you need to access any feature.

Start now to learn how to generate a private package.

Why do you show features that are not available?

We want to let you know that we're working hard to provide you great features. The first available features have been developed and tested during months.

When we provide a feature we want to make sure it's 100% bug-free, that is our best wish!

As you may know, developing great features requires time, money and quality developers.

The informations may be modified and are only here to give the basics about each feature.

Anyone can generate a package. By default, if you are an anonymous user, your package is public.

What is a package?

A package is a zip archive which contains a set of generated PHP files. These PHP files are generated by our platform using the WsdlToPhp project. The PHP files are mainly classes that represent elements found in the WSDL published.

The classes ease the calls to the operations provided by the WSDL. The operations are gathered within a limited number of classes using their name so it's easier to locate them.

It also contains a PHP sample file that shows you how to use the generated classes. It's like a starting guide which helps you understand how it works.

How do I generate a package?

To generate a package, you have to publish a WSDL with a name. The name is used to define the classes prefix. Indeed, you can customize how classes are named. The WSDL can be published using either its URI or a file containing its content or directly its content.

Several options let you the possibility to customize the package content and the generated classes behaviour.

How do I generate a private package?

Private package requires that you create an account. As soon as you log in to your account, each generated package is private. By private, we mean that only you can see it.

Is it possible to remove a package or a published WSDL?

If you generated a public package, please refer to our Terms of usage.

If you generated a private package, it can't be seen by another users. In addition, they are required to maintain the integrity of the history so you won't be able to delete them.

What is the PHP documentation?

The PHP documentation is like an online website dedicated to a package. This website is generated using the phpDocumentor project v1.4.4. It contains a page for each file and for each generated class contained by the package.

Each page is a human readable version of either:

• The class by showing a description of the class,
• Or the file that contains a class or the sample code,
• Or the classes hierarchy showing the inheritance between classes.

The advantage of this PHP documentation is that it allows to easily navigates through classes and elements that links them (used methods, overridden methods, shared properties, etc.).

How does it work?

When you ask for the PHP doc generation, it is not generated instantly. Indeed, in order to generate the documentation, the phpDocumentor script has to browse all the generated folders within the package in order to find all the files it contains. When it has found all the PHP files, it then parses them and build a tree gahering all the required informations so it can generate a page for each file and for each class it found.

Knowing this, you should understand that it can take a very short time as it can take a much longer time depending on the number of folders and files your package contains. One other factor that can slows the generation is the number of links between the classes as:

• The classes inheritance, the more the inheritance goes deep, the more it takes time,
• The call to external methods,
• The more there are links between classes, the more it takes time.

Due to this, when you ask for the generation of the PHP doc, we create an automated task that is started within the 2 minutes following your request. As soon as the generation has endeed successfully - meaning without any error, you'll receive an email telling that it worked well. This email contains the direct link to read the PHP doc.

Is it useful?

If you read the previous section, you should already have been convinced that its pretty useful.

For example, the WSDL can contain textual documentation about the WSDL elements. Each element is generated as a PHP class containing the WSDL documentation associated to it. When the phpDocumentor generates the documentation, it adds these informations to generated PHP documentation so you can read it directly from it.

Have a look to what you would access to:

Tip:  if you wish to know how it is rendered by default, have a look to the WsdlToPhp online PHP documentation.

What do you mean by using the packages online?

When you use a package online, it means that you use the generated classes without developing even one line of code. So you can validate that the generated package is functionnal and usable on your own server (according to the minimum required server configuration).

How do I use a package?

When you use a package online, it's like developing the code to send a request to the Web service except that you don't have to develop anything. Indeed, we provide an intuitive web interface to make Web service calls.

This web interface provides all what you need to:

• customize the Web service basic options
• set the soap Header to send
• set the parameters values to send

This first step is pretty easy and quick because you only have to fill form fields. The web interface looks like this:

As soon as you filled all the fields, you can then send the request by clicking the Send request button. When the response is received by our platform, the interface then displays the values returned in several parts as shown below:

As you can see, you have all the information you need to either know what went wrong or get what you expected meaning the response content.

Is it safe to use a package online?

Mostly yes. The site connexion uses a SSL certificate. The data you send to the Web service through our platform are then encrypted by the SSL certificate.

We may store some information about the calls but the database is safely protected and we surely keep secret any personal information you submit.

Why should I use a package online?

For many reasons:

• When you generate the package, you may choose the wrong options according to the Web service caracteristics. For example, some expect that you send parameters within an array containing a unique key "parameters" (ex: Sharepoint SOAP API) and some don't. This type of differenciation can be made by selecting the right options before generating the package. You can then validate the package usability,
• When you use the package online, you gain time on setting SOAP parameters, sending a request and consequently getting the response. You can quickly validate what to send to the Web service wihout developing even one line of code,
• You can easily send several requests within a short time,
• Errors are catched and displayed within a human readable way so you can identify what went wrong,
• You will be able to download the code that was dynamically generated to send the request to the Web service. The code is well written and well documented so you will only have to set the path to the package autoload. This code is ready to run the same request you made using the interface,
• By using the package online, you'll have the possibility to save the whole request in order to use it again later. It will be also possible to use it through our REST Web service that'll allow to override the request parameters.

When you publish a WSDL whatever the method you use (URI, Content or File), it is automatically stored using the native PHP DOMDocument class.

When we use this class, we activate the formatting of the content so it's prettyfied, well indented and more humanly readable.

What is the interest to download the file I published/uploaded?

It can be useful to have a cleared version of it. Anyway, we find it fun so use it or not, it's available.

How/Where do I download a WSDL file?

To download a WSDL file, you have to navigate to the WSDL page. The icon  is displayed to the right of the link that allows to watch its content (the cleared version). By clicking on this icon, a downloading window pops up to let you download the file.

Instead of downloading the whole package, you can download only one particular file.

What is the interest to download only one file?

It can be useful in the case you modified the file without keeping the original version.

How/Where do I download a PHP file?

To download a PHP file, you have to navigate to the package browser and display a file by clicking on its name. As soon as the file content is displayed, the icon   is displayed at the top right corner of the file.

By clicking on this icon, a downloading window pops up to let you download the file.

We are specialized in requesting SOAP Web services. If your business is based on SOAP Web service data or if you need to use data from one to many SOAP Web Services, we can take care of developing the program based on your business rules.

What do we use to develop?

Basically, we use a generated package as the low level layer. Indeed, as we totally know how it works, we can adapt it to your needs and add a top level layer on it. This top layer will be the core of the development.

The top layer is used to adapt the package to your environment and your technical architecture.

How do we proceed?

First of all, we need to collect all the information required to fully understand what you want to do.

As soon as we understand your needs, we'll need to be in contact with your technical service, if any, in order to adapt the development of your business program. It's important that we know if there is any technical constraint or requirements according to your environment.

Then, we'll validate with you the developing process and the steps to achieve it so we can start the development.

You'll be able to test the program in order to validate that it responds the initial request.

Finally, we'll send you a zip archive containing all the development and the technical information to integrate it into your business model.

How much does it cost?

The price depends on your account type. Indeed, if you have an account, even the Free, you'll have a discount regarding the starting price.

Learn about the devlepment price on the Pricing page.

Saving requests is available when you use a package online with the web interface. Learn more how to use it and what you can do by reading our blog post about it.

Where/When do I save requests?

Saving request is available as soon as you load an operation definition. The operation definition is the interface containing the forms to send a request for an operation.

What is it saved exactly?

When you save a request, it means that we store all the information filled in the web interface:

• The package used,
• The loaded operation,
• The SOAP options values,
• The SOAP header values,
• The HTTP header values,
• The SOAP parameters values.

As soon as you save a request for an operation, it is available each time you load the same operation of the same package.

In order to let you identify easily a saved request, we only ask you to give it a title and a short description. Each saved request is automatically dated with the current datetime.

What do I use it for?

When you call an operation often but not in the same day, you would appreciate not to set each time the same parameter values manually.

When you want to keep track of your different calls so you can finally keep only the good one(s).

As soon as the REST web service is available, you'll be able to call a saved request by its unique identifier. You'll then have the possibility to override predefined parameters in the request. Let's imagine you want to send a request to an operation for which only few parameters value differs (offset and page number for example), you can set a default request with default paremeters, save it and then call this request by only passing the missing parameters.

In the web interface, you'll have the capability to load a saved request in order to programmatically fill the fields.

Can I delete/udpate a saved request?

Of course yes, everyone has the right to make mistakes.

The data you are able to download are them you get displayed every time you receive a response after sending a request to a Web service using the web interface. Read the blog post that explains what it does and how you use it.

What data can I download?

When you send a request to a Web service using the web interface, you get a human readable version of the response. But what certainly interests you most is to get either the request or the response data usable in your own environment.

Thus, we provide you the possibility to get either the XML or the PHP version of each request and response.

What about the PHP versions?

Indeed, when we display the PHP request, we display the generated parameters and not the way we generated it. Thus, we provide you the two versions:

• The var_export() version: by calling the native PHP var_export() function, you get the interpretable version of the generated data. Then you'll just have to load the file containing the data, after loading the autoload package file,
• The generating version: when we send a request, we generate dynamic PHP code as if we had written it to instantiate the objects and send the request using the package autoload file.

With these two versions, you'll then be able to integrate the script in your environment very quickly wihout having to develop even one line of code. Moreover, as it used on our platform, the code should work perfectly on yours (according the same minimum server requirements).

The PHP version of the response will automatically be the var_export() call result in order to let you load it in your environment using the autoload file.

What about the XML versions?

The XML request is maybe the most interesting one because it helps understand how the request must be built.

The XML response can be useful too if you also want to understand how it is returned by the web service. Moreover you can parse it your way using a XML parser when the response contains XML which does not match with PHP classes.

The remote package usage is available. If you wish to learn how to use it basically, please read the first blog post on how to call any SOAP Web service using a REST Web service.

What do you mean by remote usage?

We provide a REST Web service which gives the possibility to use programmatically your package from your own environment through our platform instead of using the web interface we provide.

Why do you provide a REST Web service to call a SOAP Web service?

Some would say that it would be clever to provide a SOAP Web service than a REST Web service. But our goal is to help you forget about SOAP and finally deal with a REST Web service.

Indeed REST is nowadays the most used method to communicate with a Web service in general. Plus, you are maybe on our platform because you didn't know how to call the SOAP Web service. So why would you want to call a SOAP Web service which would then use your package?

Is it possible that you provide a SOAP Web service instead of a REST Web service to use a package remotely?

If many users ask for it, maybe we will.

Why should I use my package through your platform instead of using it from my environment?

For many reasons:

• Your environment does not provide the native PHP SoapClient class because of your PHP version or configuration. But you will always have the possibility to call the native PHP function file_get_contents() which can be enough to call a REST Web service,
• As explained in the section concerning the package online usage, you can call a pre-defined operation saved within your account. By this way, you can easily call operation with a few parameters,
• We provide an environement adapted to call SOAP Web services and we catch all errors that can happen so everything is under control. You are then informed of everything that went wrong or not,
• By using your package through our platform, you have an history of all your calls. For example, if you pay for each request you send to a Web service, you will be able to easily validate the number of calls you sent by going to your account usage history.

What is it exactly?

Automated workflows is like a calendar where you schedule SOAP calls. Each workflow is independant and has its own frequency, start date, end date and finality. By finality, we mean that you'll be able to tell what you expect from it:

• Receive the data by email (in XML or CSV or TXT) or simply an alert,
• Insert the data in a local Database to manipulate/extract them later in your preferred format,
• Insert the data in a remote Database to manipulate/extract them later in your preferred format,
• Call a distant Web service to send it the data,
• Receive the data on a FTP server (in XML or CSV or TXT).

Scheduled SOAP calls are defined by you from an operation and let you the possibility to make several calls in the same workflow (first call: login to get a token, second call: get data sending the token, etc.).

When should I use automated workflows?

Automated workflows are useful as soon as you need to call a Web service to retrieve data hourly, weekly, monthly or even annually. The minimum frequency for a workflow is every 15 minutes. Indeed, as each Web service has its own limit (response time, calls per hour, etc), we make sure we don't overload them. In any case, be sure to have right to call the Web service at a certain frequency before scheduling it.

Is it easy to configure automated workflows?

We make it as easy as it could be. Scheduling workflows is like scheduling an appointment on your calendar. It then requires that you set:

• The title: name of the workflow,
• The description: short text describing what the workflow is used for,
• The starting date: using a calendar, you'll be able to easily select the date from which the workflow must start,
• The starting hour: the hour the workflow must start at,
• The ending date: using a calendar, you'll be able to easily select the date until the workflow must be executed,
• The ending hour: the hour until the workflow must be executed,
• The frequency: you'll be able to set the frequency from the minimum frequency fragment of 15 minutes to the maximum frequency fragment of one year,
• The tasks, you can define one or several consecutive tasks within the workflow. Each task is defined by:
  • The package:
    • Automatically selected if you are in a package,
    • Otherwise select the package containing the operation to call,
  • The operation:
    • Automatically seleced if you are in a package and you have already loaded an operation,
    • Otherwise select the operation contained by the package previously selected,
  • The request:
    • A saved version associated to the operation you have loaded,
    • A saved version associated to the operation you selected previously,
    • Built the request in place,
  • The result, select how the response is managed on success:
    • Receive data by email in XML, CSV, TXT or simply an alert,
    • Insert data in a local database,
    • Insert data in a remote database,
    • Call a Web service,
    • Receive the data on a FTP server,
• Notification: lets you define which person must receive a notification by email each time the workflow is executed (by default, you always receive a notification by email on your personal account email address)

It may seem tricky but the usage will be really trivial.

Support is an integrated message center into the platform in order to ease the communication between you and us.

You'll have to use this message center in order to send us request regarding the usage of our platform because email or contact message won't be treated as soon as you have an account.

Why should I use the Support?

The Support will help you if you encounter issues using our platform. Each time you'll need to ask us a query, you will need to send a message via the message center.

This message center is useful because it helps gathering information that could be useful in the future to you or to us.

Moreover, if you encounter an issue which is encountered by many users, we'll make it public to anyone. In order to make it readable to anyone, we'll only display it without any personal information.

Can I suggest improvements?

Of course yes, we would be pleased! Each suggestion will be shared with the other connected users. The goal is to let users vote for what they need most. Each month, the most popular suggestion will be developed.

Can I send you an email?

If you have an account, you can't. You must use the message center otherwise you'll get no anwser. If you contact us using an email that is not your primary account email, you'll be charged consequently.

If you haven't an account, you must use the contact form in order to send us a message.

If you send us direct email, you won't get any anwser. We may seem rude, but it's our best way to provide the best service level.