API C# Class Lib

Hi, I can see there’s a SOAP endpoint, and I can see that visual studio pulls in the methods supported, however am I right in thinking one still has to write the XML to be passed in?

Has anyone created a set of classes that can just be serialized/de-serialized in C#? If they have it would of course save a LOT of time and ensure the XML being passed in is correct. I could only find individual XSD files too, not one complete schema (which could be used with the xsd tool in.NET to generate the classes).

Any assistance on this would be appreicated, I need to get invoice creation done from out central billing system.

Cheers, Ben

In Visual Studio you used to be able to enter the asmx endpoint and it would build all the classes for you. I’m not sure if this guide helps:

Let me know how you get on.

No, that simply creates the methods that can be called on the ASMX endpoint. Your ASMX definition quite clearly states (and i assume this is why class structure is never passed with the endpoint) that the body of each call is XML

https://quickfile.co.uk/WebServices/API/invoices.asmx?op=invoice_create

So if someone makes a call over SOAP, they have to create the XML manually. Just seems like a pain in the bum really.

Any tips? Is there one big xsd file rather than me downloading each one and using xsd tools for .NET to generate the classes?

The SOAP endpoint was created a few years back by a developer who has since moved on. As I understand it the SOAP interface we have only grabs the XML string and performs all operations manually by parsing the XML. In that regard there is no abstraction from the XML that would allow you to work with a set of classes to simplify integration. Any integration therefore would require you to concatenate the XML and post it as a string.

All the XSD schemas are contained in unique files for each method and are used on our side as the first point of validation. So I’m afraid we don’t have them all lumped into one XSD file.

Boo! Never mind. Shame though, it would make integrations very quick and easy. Having a good functional C# API would make it a lot easier to develop applications for quickfile. Could you send me a zip file or something with all the XSD files in maybe? Save me having to go from page to page and save them? I would consider sharing my code on github so any other C# devs don’t face the same hurdle.

It would indeed be a great addition and certainly something we’d like to push forward in the future. These last few years we’ve been stretched to the max trying to build out functionality in the main web application, some updates to the API have taken a back seat.

We are now seeing more interest in the API so there’s more of an imperative to improve the documentation, examples and general accessibility. Some sort of wrapper we could make available through Nuget would be incredibly useful!

Anyway here’s our XSD library. Each schema in the invoices folder references the BaseTypes.xsd for the header (authentication) node along with some common types.

QuickFile_XSD_Schemas.zip (47.3 KB)

Please let me know if there’s anything else I can assist with.

Great! Yeah having something in nuget would be good. I’ll see what I can throw together, and I’m happy to open it up on github. I have a few projects in nuget already so it’s quite easy to do. Keep you posted.

1 Like

Sounds good! Let us know how it goes.

Quick question about the returned XML.When i send a create_invoice schema, the namespace has to be included.However, the returned XML doesn’t include it. This poses somewhat of an issue for .NET’s XML Deserializer. without the namespace, the XML doesn’t match the class definition.

Is there a reason for this being missing in the returned XML. E.g.

I send:

<Invoice_Create xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="http://www.QuickFile.co.uk">

but I get back:

<Invoice_Create>

To be honest I couldn’t say for sure? We could look at setting a preference on the app to include the namespace in the response, although regrettably it’s probably not something that we’ll be able to implement in the next few weeks as we are quite stretched with other commitments at the moment.

For consistency it might be useful.I will try and manually manipulate the incoming messages in the mean time, as a temporary hack.