Skip to main content

We have been successfully using the API end-point since around March 2024 with a custom built plugin in WordPress Gravity Forms on our USA server. The custom plugin uses the composer package docusign/esign-client ^6.10 behind the scenes. 

In mid august we migrated our setup to new server in the EU. 

Since migrating to a fully patched ubuntu 24.04 server (no java or log4j), using a LAMP stack, all of our API calls get HTTP 444 with the vague error message “The custom error module does not recognize this error.”

If we run “curl -v  https://na4.docusign.net/restapi”  on the cli from the new server we receive this response:
 

< HTTP/1.1 444 
< Content-Type: text/html
< Vary: Origin
< X-Content-Type-Options: nosniff
< X-DocuSign-TraceToken: c247ca85-1505-4838-9d76-693daec3245d
< X-DocuSign-Node: SE101FE106
< Date: Wed, 08 Oct 2025 17:14:15 GMT
< Content-Length: 54
< Strict-Transport-Security: max-age=31536000; includeSubDomains

* Connection #0 to host na4.docusign.net left intact
The custom error module does not recognize this error.


If we run “curl -v  https://na4.docusign.net/restapi” on the cli from any of our VMs (all ubuntu 24.04), from either EU or from USA, we receive this response:

 

< HTTP/1.1 200 OK
< Cache-Control: no-cache
< Content-Length: 685
< Content-Type: application/json; charset=utf-8
< Vary: Origin
< X-Content-Type-Options: nosniff
< X-DocuSign-TraceToken: bd6c48b1-b6f6-40ac-976d-be809dfdf318
< X-DocuSign-Node: SE101FE122
< Date: Wed, 08 Oct 2025 17:15:49 GMT
< Strict-Transport-Security: max-age=31536000; includeSubDomains
<
{
"serviceVersions": [
{
"version": "v1",
"versionUrl": "https://na4.docusign.net/restapi/v1"
},
{
"version": "v2",
"versionUrl": "https://na4.docusign.net/restapi/v2"
},
{
"version": "v2.1",
"versionUrl": "https://na4.docusign.net/restapi/v2.1"
}
],
"buildVersion": "25.3.100.61019 (25.3.01.00.61019+a93ef2311838)",
"linkedSites": [
"https://www.docusign.net",
"https://na2.docusign.net",
"https://na3.docusign.net",
"https://eu.docusign.net",
"https://au.docusign.net",
"https://ca.docusign.net",
"https://na4.docusign.net",
"https://jp1.docusign.net"
]
* Connection #0 to host na4.docusign.net left intact
}

When we move the server we tucked it behind Cloudflare. We remove Cloudflare shortly after we realized our new server was no longer working. 

We are at a bit of a loss as to what to look for next. Support has said we are not paying for that level of support and offers no advice. Are we overlooking some obvious issue? The lack of error message is making this a challenge. Is it possible that DocuSign has add our IP address to a block list of some sort? Any suggestions welcome. 

@JesseJames 

I am unaware of that specific error message, but was able to find this Docusign error codes overview.

Error code: 444  - No response: The client receives no information from the server, including the 444 status code itself.

It appears that your new server is unable to connect to Docusign.
→ Have you read this article, specifically “Allowlists for Docusign eSignature service” and configured your new server accordingly? 

If your Docusign server is in the EU, the correct baseURI should be https://eu.docusign.net.
You can verify this by logging into your Docusign eSignature account as an Administrator.
→ This is not the issue here, as the error code would be most likely 401 - Unauthorized, when making subsequent API calls that require Authentication.

PHP SDK Version 6.1. is outdated and probably 4 years old and may require an update.
The current version 8.4 and can be found here on GitHub.
→ While highly recommended to update to the latest version, this is not the root cause.

I am a bit confused about your last sentence: What level of support are you paying for?
→ Support could check, if your IP address was blocked and may be able to unblock it, but this would probably result in 403 - Forbidden error code.