Want to learn about some of the most common REST API Response Errors in OnBase and their responses? This blog and the video below will get you started.

Common REST API Response Errors

Your Guide to Common REST API Response Errors in OnBase

First, there are a few common REST API error messages that you’ll definitely benefit from knowing about. Most of the response messages you’ll get will be pretty self-explanatory, but some of them will require a little more digging.

Before we get into it, let’s look at a couple of examples of some of the responses you may get where it is what it says on the tin.

Example 1:

In this video example, we did this solely in Postman, but if you have an application that utilizes the API, you may see these messages in the diagnostics console.

Initially, in this video example, we were trying to make a simple connect call to get a token. As a response, we got a four hundred error response with the description of “invalid username or password.” Since we entered the wrong password, this isn’t too surprising. So, we had to correct that issue to get a valid response.

Example 2:

Next, it’s time to get the keywords for a specific document using that document’s ID.

In our example, it was initially set to retrieve the keywords for document 11384, but let’s go ahead and change this to something else – for the sake of the example, we made a typo. As a result, we got a four zero four response with this one, “could not find document ID 1”.

In this case, we didn’t actually have a document in OnBase with ID 1, so this is the correct response. Now let’s change it back to “11384”, which we know for certain exists, and we get a valid response again.

Example 3:

For this third request, we’re going to try to delete a document. Initially, we were getting a 403 forbidden error, and the message, “document 11383 has been checked out by another user, unable to delete.” If it’s checked out or locked, we should be able to see that in the locks in the Unity Client. When we went to check, the document we were trying to delete was in fact there, so we removed the lock and tried again and were able to successfully delete it. We knew that this was safe to do because we were the only one in the system, but if you know others may be in your system working on a document, be wary. It may be that you’re trying to delete a document that is still needed, in which case you should double check the document ID to make sure you’re deleting the correct one.

Less Obvious Examples

Now let’s take a look at some examples that may or may not be as obvious.

Example 4:

First, we decided to try to make a call to archive a document. The keywords were already added, and the document had been uploaded. This last part is just to essentially commit the document in OnBase.

When we ran this request, we received a 400 bad request error saying some of the provided input data is invalid. This means that some of the information in the body that we input is incorrect.

More specifically, the error says “could not find document type”. When we looked at the top of the screen, it showed that we set it to 201 as the document type. Now, we knew we wanted this document to be uploaded as an AP check doc type, so we went ahead and did the config and looked to see what that document type was. The answer was 202, which makes more sense as to why our original 201 input gave us an error code. When we went in and corrected this and sent up the document again, all was resolved.

Example 5:

With this request, we’re trying to get the properties of a document. The first call made here was a success, as it brought back the information we were looking for. However, now we’ve changed something and want to make the call on a different document.

Right away, it appeared as if something was wrong, as it gave us a 400 response with “some of the provided input data is invalid” again. The more specific details gave us “collection value cannot be null or empty.”

So in this request, we used a variable to input the document ID. And in the console below it, we could see the actual request that was being made. You can see in the video here how there is no document ID here compared to the successful ones above it.

Looking at our variables, it looks like we actually forgot to put in the new document ID. We went back and filled that out to try again, which gave us another successful call. As a result, we were able to see the document ID in the console in the call at the bottom.

Example 6:

These next two examples are going to be a bit more obscure in their resolution.

First, we tried to make a call to get the properties for the document with ID 10338. When we made the call, we got a pretty different response compared to the last 5 examples we’ve examined. We got a 404 not found error. This can mean that the call isn’t able to find the server, so we decided to double-check our request and make sure there weren’t any mistypes.

It ended up looking like we typed “app server” instead of “API server”. That’ll do it! We went in and fixed that and sent the request again, and we got the correct response.

Again, this is a more complicated example in terms of resolution, so just to break it down a little bit further, when we get a 404, we’ll want to double-check the entire URL, which usually goes something like this:

HTTPS, then server name, then API server instance, then the rest of the call, which in this case, since we were trying to retrieve a document by ID, we’ll go OnBase, core, documents, and then the document ID.

But really, we would want to make sure this first part is calling the correct server.

Example 7:

For this last example, we were trying to archive another document, and we were getting a 403 forbidden. And it said, “user does not have rights to create, modify, hidden, and or read only keywords.”

Now, when we double-check this one, we’ll see that the user logging in to make these requests does in fact have the correct permissions.

So knowing that information for fact, this is going to be one of those tricky situations where the response message isn’t necessarily exactly what the issue is.

It’s easy to overlook this when making something, but we need to ensure that the keyword GUID is unique for each request.

So let’s go ahead to the first step of this process when we are first creating this document. Here at the bottom is the keyword GUID we should be working with for this request. Let’s check it against the one we already have.

And as you can see, we forgot to replace it with the new value, so it’s trying to still upload using our old GUID. Once we switch it to the new one, and now we have a valid response.

Final Note on REST API Response Errors in OnBase

So these are just some examples of the error messages you may receive, but most of them are pretty straightforward where the error is what needs to be fixed.

Want to Expand your OnBase Knowledge?

Bookmark our Question Corner playlist on YouTube. Every other week, we add a new OnBase demo led by experts from the Naviant Customer Success Team. Each demo is 3-10 minutes long and answers questions frequently asked by OnBase users like you.

View Playlist

Want More Content Like This?

Subscribe to the Naviant Blog. Each Thursday, we’ll send you a recap of our latest info-packed blog so you can be among the first to access the latest trends and expert tips on workflow, intelligent automation, the cloud, and more.