The Mautive API is a great way to interact with the software through your own interface, providing you full access to data and functionality to use in any way you can imagine.
Even though our API is well documented and we provide examples and language-specific wrappers, often times you’ll run into an issue that you can’t find a solution for and need to contact Mautive support.
We welcome all support requests so you should never feel embarrassed or silly for contacting us. In fact, a lot of times there might be an issue that we are not aware of until someone points it out. We want developers to feel comfortable using our product and API, and that includes finding answers when you need them. You can reach us through our community forum, Twitter profile, or standard support email address.
That being said, the most common things we’ll ask for when troubleshooting your API issue are as follows:
- The full API request URL (including all parameters)
- If it’s a POST request, your POST data (pretty-printed JSON if possible)
- The expected response/action (what do you think should happen after making this request?)
- The actual response received from the server, and action performed (if any)
This gives us a great idea of what you are attempting to do, and the important interface pieces that you are using. With this information we can typically narrow down the issue and provide an accurate response in a timely manner.
In general, be as detailed as possible. This ensures that 1) the support rep understands what you are attempting to do with the API, and 2) can effectively replicate the issue (in order to troubleshoot it).
In other (more rare) cases it can be much harder to isolate what the problem could be. Read on to learn why.
The challenge with API troubleshooting
The API is especially hard to troubleshoot because there is no visible interface that Mautive support can go to in order to see what the issue is. The interface is being created by you, so support can’t possibly know what is happening within your own application, script, or environment.
Consider this analogy: You’re building a large project made up of several components/materials purchased from a home improvement store, each of which have detailed instructions on how to use. You run into a problem with one component – despite the instructions it’s just not working properly within the scope of your entire project. You go back to the home improvement store and tell them the individual component is not working.
The staff at the store won’t know the entire scope of what you’re building and therefore can only test that the individual component is working unto itself. If there’s some other aspect of your project that is affecting this one component, the staff won’t know what that is.
This is similar to how an API works. An API is made up of individual instructions that, when connected to your application code, make up the functionality for an application. An API is just a set of instructions. How you execute those instructions in your application environment is entirely up to your system and skill level.
An application is also made up of different components – one of which may be the Mautive API, others could be several different company API’s. Combine all that with server processing, interface elements, client viewports and devices, and your own application logic – and you have many variables involved with how the application behaves. It’s easy to think that one component is causing a problem when it could be something else entirely.
Whereas we can’t possibly know what every application is doing, we can try to provide helpful examples and pointers to provide you with a good starting point so you can focus on other areas of your application. Combine that with a friendly, helpful support staff, and quite often the answer will reveal itself by simply having more than one person involved and listening to your situation. This is what we strive to provide, so if there’s anything we can do to improve our support or API, always let us know.
