Skip to main content

We have a big problem with e-Signature APIs. They do NOT report error properly in a RESTful manner.  We should NEVER have silent failures where the HTTP status response code states a happy 200 status, but the response body contains an error message.  This is an anti-pattern, as we should never be forced to introspect a response body to look for errors and throw our own exceptions. We should be catching these as errors as either 4xx or 5xxx series errors.

The renowned Martin Fowler provides a nice Reader’s Digest condensed version of Richardson’s Maturity Model.

From https://martinfowler.com/articles/richardsonMaturityModel.html#level2

“There is another difference if something goes wrong, such as someone else booking the session.

HTTP/1.1 409 Conflict
cvarious headers]

The important part of this response is the use of an HTTP response code to indicate something has gone wrong. In this case a 409 seems a good choice to indicate that someone else has already updated the resource in an incompatible way. Rather than using a return code of 200 but including an error response, at level 2 we explicitly use some kind of error response like this. It's up to the protocol designer to decide what codes to use, but there should be a non-2xx response if an error crops up. Level 2 introduces using HTTP verbs and HTTP response codes.”

Thank you for your post, Scott!

You are absolutely right, and your suggestion makes sense to me and to many developers using REST APIs. As experts explain, the HTTP status code 200, often written as "200 OK," indicates that the server has successfully processed the client's request and returned the requested data. It signifies a successful outcome, meaning the server understood the request and delivered the requested content without any errors.

However, in the example you provided, this was not the case. An envelope was not created because not all the necessary information was provided to Docusign to complete the process. To create an envelope, at least one document and one recipient are required, or you can use a template.
I'll admit that the Docusign eSignature API is not perfect, but it remains a highly useful and powerful tool. Your feedback is invaluable and will help us design future versions of the API that are more intuitive for developers and better aligned with industry standards.


Please continue sharing your thoughts and suggestions about our APIs and developer technologies. We truly value your input. Also, I'd love for you to explore some of our latest innovations, including Maestro, Navigator, and Extension Apps.
Lastly, keep an eye on this community page for updates about our developer tools and technologies.


Best regards,
Inbar


Thank you for your post, Scott!

You are absolutely right, and your suggestion makes sense to me and to many developers using REST APIs. As experts explain, the HTTP status code 200, often written as "200 OK," indicates that the server has successfully processed the client's request and returned the requested data. It signifies a successful outcome, meaning the server understood the request and delivered the requested content without any errors.

However, in the example you provided, this was not the case. An envelope was not created because not all the necessary information was provided to Docusign to complete the process. To create an envelope, at least one document and one recipient are required, or you can use a template.
I'll admit that the Docusign eSignature API is not perfect, but it remains a highly useful and powerful tool. Your feedback is invaluable and will help us design future versions of the API that are more intuitive for developers and better aligned with industry standards.


Please continue sharing your thoughts and suggestions about our APIs and developer technologies. We truly value your input. Also, I'd love for you to explore some of our latest innovations, including Maestro, Navigator, and Extension Apps.
Lastly, keep an eye on this community page for updates about our developer tools and technologies.


Best regards,
Inbar

Do you AGREE that the API should have returned a 422 or similar?  Or not?

422 Unprocessable Content - The request was well-formed but was unable to be followed due to semantic errors.


The problem is that platforms like Azure Application Insights could be falsely report a high degree of success whereas the are silent failures.  To suggest that the REST client introspect every HTTP 200 response body is NOT a reasonable ask.  That is NOT going to happen -- that is the anti-pattern. 

Perfect your core competencies before jumping to the shiny object.


Scott, I already said:


You are absolutely right


This means you won the debate, no need for further arguments 😂

So, yes, I agree it should not return 200 in this case (and other such cases). 

Let me know if there’s something else I can help you with, would love to learn more about how you are using the Docusign APIs.


@Inbar.Gazit   I personally view this as a ‘collaboration’ and not a debate, as we must work together to identify and resolve issues.  Cheers, Scott.


This was a joke (hence the smiley icon) 

Can you maybe share a bit more about what your team is building?