Have you tried use Postman and the examples it produces in Java to get you started? Apologies if you have already gone down this route.
The REST Users guide gives you examples on how to get started with Postman. You can find the REST users guide in the application help.
I hope that helps.
BTW. I have no Java experience.
Sounds like you are having invalid certificate errors.
Let’s get some background info.
Is this cloud, or on prem.
If on prem, what is your certificate situation?
Calling locally or from external? Self-Signed or full cert?
BTW, welcome to the forum!
To format code/text use three backticks(grave) before and after:
Usually to the left of the 1 key, and under ~
` ` ` <- Like this before and after, but NO spaces
--> Code/Formatted Text Here
` ` ` <- Like this before and after, but NO spaces
You can also do a single backtick before and after on a single line to do this:
example
I fixed your post so it was easier to read.
Postman test is good. 
“REST Users guide” is from EPICOR?
It is on-prem environment. We don’t have a signed cert for the testing environment yet. However, from a typical REST test (like postman), I don’t have any issues.
I do have Java keystore preparation done. However, I can’t verify if it works or not.
Frome swagger generated by online tools (yaml → java POJO), I don’t find any method to let me add the basic authorization info for making the call. I modify the ApiClient.java constructor by adding the HttpBasicAuth and ApiKeyAuth so that it won’t throw exceptions while getting objects from the authentications map object.
==================== ApiClient.java constructor I modified for test =================
authentications = new HashMap<String, Authentication>();
// SENTEC Specific Authentication objects
HttpBasicAuth hba = new HttpBasicAuth();
hba.setUsername(appConfig.getApiuser());
hba.setPassword(appConfig.getApipwd());
authentications.put("basicAuth", hba);
ApiKeyAuth auth = new ApiKeyAuth(appConfig.getKeystore(), "X-API-KEY");
auth.setApiKey(appConfig.getApikey());
auth.setApiKeyPrefix("x-api-key");
authentications.put("apiKey", auth);
// Prevent the authentications from being modified.
authentications = Collections.unmodifiableMap(authentications);
====================================================
Do I do something wrong here?
Thanks for the tips!
I don’t think so.
I’m pretty sure your problem is java not liking your self-signed cert. You’ll probably have to find a way to ignore it.
Or…
I got the impression this was temporary.
If you’ve got postman working, then I’d say the guide will be of little use…
If you are still interested, just search for “REST” in the application help. or in the document downloads on EpicWeb
2023.1 REST V2
2023.1 REST V1
2022.2 REST V2
2022.2 REST V1
2021.1 REST V2
2021.1 REST V1
and so on…
You need EpicWeb login ability to get these documents
What is temporary? 
It’s usually an adjective meaning:
lasting for only a limited period of time; not permanent.
—-
And we are waiting for…? My suggestion is that one can easily spin up dev environments with real certs and avoid these kinds of issues altogether. 
Yes we know, and we love you for it.
Back here in normal land, we don’t always do that lol.
The hard part is knowing when truly temporary is.
If you can’t do that, you should probably always practice best practices.
Sure. In this case however, we do know that self-signed certs only work if all the communication is on the same machine. That is why a Visual Studio dev cert always works for local development. But the moment we try to communicate outside our machine, we’re wasting a crap-ton of time trying to work around it. We know the definition of insanity afterall.
And I’m not suggesting that my solution is the best or only one. It fulfilled my requirement for automation with the new cert lifetimes shrinking. I bet @EarlGrei has some clever tricks up his sleeve that makes this easier too. If we want to pain to stop, having a real cert should be the best practice in normal land. No?
Certify the web makes it so stupid simple every server we have, temporary or not, gets setup with it if it’s going to host anything.
The ONLY thing we use our CA for at all (other than base use for AD) is my dev certificates for stuff I publish using ClickOnce
Using Certify paired with a supported EXTERNAL DNS Host, like Cloudflare (what we use), you do not have to even bother exposing the service to the internet to get the SSL certificates to validate. We only have 1 server that is exposed to the internet on ANY ports but we have several that run Certify for various purposes. ALL are getting Lets Encrypt valid certificates for our domain.
Do we really? 
I am certainly not either. I have my workflow, others have theirs.
I try to promote balance in how I work, but I also have a lifetime of
dealing with ADHD to lean on. I’ve learned the hard lessons on what
I deal with today vs tomorrow.
It should.
I’m only saying, IF you have the discipline, choose what works best for you in the situation.
If you do not, always color between the lines.
I have areas of my life where I must stay between the lines, because I’ve either learned a hard lesson, or it’s more important to do it right the first time.
Other areas are more flexible.
Don’t change Mark.
Flexible is my wife’s favorite “F” word, at least that’s what she tells her college students.