Forem: Shubham Bhati

Calling OpenAI from Spring Boot: A Production-Ready Integration

Shubham Bhati — Mon, 18 May 2026 07:09:47 +0000

Published 2026-05-18 by Shubham Bhati — Backend Engineer (Java 17, Spring Boot, Microservices).

We've all been there - trying to integrate a third-party API into our Spring Boot application, only to hit a roadblock. Recently, we encountered this issue while trying to integrate OpenAI into our Java backend using Spring Boot. The primary goal was to create a seamless Spring Boot OpenAI integration, enabling our application to tap into the power of AI. After overcoming several hurdles, we successfully implemented the integration, and our application is now capable of utilizing OpenAI's features.

Introduction to OpenAI API
Setting up OpenAI with Spring Boot
Creating a Service to Handle OpenAI Requests
Error Handling and Logging
Performance Optimization
Common Mistakes
FAQ
Conclusion

Introduction to OpenAI API

The OpenAI API provides a wide range of features, including text completion, language translation, and text classification. To use the OpenAI API, you need to create an account on their website and obtain an API key. We're using Java 21 and Spring Boot 3.2 for our application, which provides a solid foundation for building a production-ready integration. The OpenAI API uses a RESTful architecture, making it easy to integrate with our Spring Boot application. We can use the Spring Web module to make HTTP requests to the OpenAI API.

// Import necessary dependencies
import org.springframework.beans.factory.annotation.Value;
import org.springframework.http.HttpEntity;
import org.springframework.http.HttpHeaders;
import org.springframework.http.HttpMethod;
import org.springframework.http.ResponseEntity;
import org.springframework.web.client.RestTemplate;

// Create a RestTemplate instance
RestTemplate restTemplate = new RestTemplate();

// Set API key and base URL
@Value("${openai.api.key}")
private String apiKey;

@Value("${openai.base.url}")
private String baseUrl;

// Create a method to make requests to the OpenAI API
public String makeRequest(String prompt) {
    // Set headers and entity
    HttpHeaders headers = new HttpHeaders();
    headers.set("Authorization", "Bearer " + apiKey);
    HttpEntity<String> entity = new HttpEntity<>(headers);

    // Make the request
    ResponseEntity<String> response = restTemplate.exchange(baseUrl + "/completions", HttpMethod.POST, entity, String.class);

    // Return the response
    return response.getBody();
}

Setting up OpenAI with Spring Boot

To set up OpenAI with Spring Boot, you need to add the necessary dependencies to your pom.xml file (if you're using Maven) or your build.gradle file (if you're using Gradle). We're using the Spring Boot Starter Web module, which provides a convenient way to build web applications. You also need to configure the OpenAI API key and base URL in your application properties file.

# application.properties
openai.api.key=YOUR_API_KEY
openai.base.url=https://api.openai.com/v1

Creating a Service to Handle OpenAI Requests

To handle OpenAI requests, we created a service that encapsulates the logic for making requests to the OpenAI API. This service uses the RestTemplate instance to make HTTP requests to the OpenAI API. We're using the Spring Framework's dependency injection feature to inject the RestTemplate instance into our service.

// OpenAI Service
@Service
public class OpenAIService {
    @Autowired
    private RestTemplate restTemplate;

    public String makeRequest(String prompt) {
        // Make the request using the RestTemplate instance
        ResponseEntity<String> response = restTemplate.exchange("https://api.openai.com/v1/completions", HttpMethod.POST, new HttpEntity<>(prompt), String.class);

        // Return the response
        return response.getBody();
    }
}

Error Handling and Logging

Error handling and logging are crucial aspects of building a production-ready integration. We're using the Spring Framework's exception handling feature to handle exceptions that occur during the execution of our application. We're also using the Logback logging framework to log important events in our application.

// Error handling example
try {
    // Make the request
    String response = openAIService.makeRequest(prompt);
} catch (Exception e) {
    // Log the exception
    Logger.getLogger(OpenAIService.class.getName()).log(Level.SEVERE, null, e);
}

Performance Optimization

Performance optimization is critical to ensuring that our application can handle a large volume of requests. We're using the Java 21's built-in support for concurrent programming to optimize the performance of our application. We're also using the Spring Boot's support for caching to cache frequently accessed data.

// Performance optimization example
// Use Java 21's concurrent programming features to optimize performance
ExecutorService executor = Executors.newFixedThreadPool(10);
Future<String> future = executor.submit(() -> openAIService.makeRequest(prompt));

Common Mistakes

Here are some common mistakes to avoid when integrating OpenAI with Spring Boot:

Not handling exceptions properly
Not logging important events
Not optimizing performance
Not configuring the OpenAI API key and base URL correctly
Not using the correct dependencies in your pom.xml or build.gradle file

FAQ

What is the OpenAI API?

The OpenAI API provides a wide range of features, including text completion, language translation, and text classification. You can use the OpenAI API to build applications that utilize the power of AI.

How do I integrate OpenAI with Spring Boot?

To integrate OpenAI with Spring Boot, you need to add the necessary dependencies to your pom.xml file (if you're using Maven) or your build.gradle file (if you're using Gradle). You also need to configure the OpenAI API key and base URL in your application properties file.

What is the difference between Spring AI and OpenAI?

Spring AI is a framework for building AI-powered applications, while OpenAI is a platform that provides a wide range of AI features, including text completion, language translation, and text classification.

Can I use OpenAI with Java?

Yes, you can use OpenAI with Java. OpenAI provides a RESTful API that can be accessed using Java's built-in support for HTTP requests. You can use the Spring Web module to make HTTP requests to the OpenAI API.

Conclusion

In this article, we've discussed how to integrate OpenAI with Spring Boot. We've covered the basics of the OpenAI API, how to set up OpenAI with Spring Boot, and how to create a service to handle OpenAI requests. We've also discussed error handling and logging, performance optimization, and common mistakes to avoid. To learn more about Spring Boot and OpenAI, you can visit the Spring Boot documentation and the OpenAI documentation.

15 Production Incidents in a Healthcare Backend: FHIR Lessons

Shubham Bhati — Mon, 18 May 2026 07:08:58 +0000

15 Production Incidents in a Healthcare Backend: What FHIR Taught Me About Reliability

By Shubham Bhati — Backend Engineer at AlignBits LLC

When I joined IHX Private Limited in June 2023 as an Associate Software Engineer, I had Masai's certificate and a few personal Java projects. By the time I left in August 2024, I'd resolved 15+ production incidents on FHIR-standard healthcare backend systems.

That number sounds bad. It isn't. Production engineering is where you actually learn to build software. Here's what FHIR healthcare backends taught me — beyond what any Spring Boot tutorial covers.

What FHIR is (in 60 seconds)

FHIR — Fast Healthcare Interoperability Resources — is a standard for exchanging healthcare data. Think of it as REST + JSON for hospitals, labs, insurers, and EHR systems.

Every domain object is a "Resource": Patient, Practitioner, Encounter, Observation, Coverage, Claim. Each has a well-defined JSON schema with strict validation rules.

In Java, the standard library is HAPI FHIR. It's huge, opinionated, and 95% of what you need.

What "production" means in healthcare

In a typical SaaS, an outage costs revenue. In healthcare:

A patient might not get their meds approved.
A claim might be misrouted.
A practitioner might see wrong data.
Regulators audit your logs.

This isn't fear-mongering. It's why FHIR healthcare backends force you to learn engineering disciplines that consumer apps let you skip.

Lesson 1: Schema validation is not optional

Patient records flow in from ~20 different EHR vendors. Each interprets FHIR slightly differently. Some send dates as YYYY-MM-DD, others as full timestamps, some omit required fields, some send extension data your parser doesn't recognize.

What we learned: validate at the boundary, log the failures, never crash the pipeline.

@Component
public class FhirValidator {
    private final FhirValidator validator;

    public ValidationResult validate(IBaseResource resource) {
        ValidationResult result = validator.validateWithResult(resource);
        if (!result.isSuccessful()) {
            log.warn("fhir.validation.failed resource={} errors={}",
                resource.fhirType(), result.getMessages());
            // do NOT throw — route to dead-letter for human review
        }
        return result;
    }
}

Bad validation handling caused 4 of our 15 incidents. Fixed it once, gone forever.

Lesson 2: Idempotency or death

Healthcare integrations retry. A lot. Network blips, gateway timeouts, scheduler restarts — every one triggers a retry. If your handler isn't idempotent, you create duplicate Observation records for one blood test. Patients now appear to have run a CBC twice.

The fix: every inbound FHIR message has a deterministic ID. Use it.

public Observation upsert(Observation obs) {
    String idempotencyKey = obs.getIdentifierFirstRep().getValue();

    return observationRepo.findByIdempotencyKey(idempotencyKey)
        .orElseGet(() -> observationRepo.save(obs.withKey(idempotencyKey)));
}

We turned every write into an upsert keyed on a stable business key. Duplicate-record bugs dropped to zero.

Lesson 3: The clock is not your friend

Different sources stamp their FHIR resources with different time zones. UTC, IST, sometimes naïve local time with no zone. Sometimes the clock is wrong.

Rules I now follow:

Parse everything to Instant at ingress — never LocalDateTime.
Store as UTC in the database.
Format to user's locale only at the edge (controller / response mapper).
If a timestamp has no zone, treat it as suspect and log it.

Caused 3 of our incidents. Twice the bug was "patient timeline shows future appointment" because someone stored IST as UTC.

Lesson 4: Don't trust the network — design for partial failure

FHIR integrations are a graph of remote calls: ingress webhook → validation → transform → enrichment from EHR → push to insurer. Anywhere in the chain can fail.

Patterns that work:

Every step is independently retryable
Every step writes to a durable store (DB or queue) before moving on
A failed step doesn't block other patients' messages
A circuit breaker protects you from a slow downstream

We standardized on this pattern after an incident where one slow insurer API caused a thread pool to fill and blocked all unrelated patient traffic. Resilience4j circuit breaker fixed it permanently.

Lesson 5: Logging structure matters more than log volume

When you're paged at 2am, you don't want to grep 10GB of unstructured logs. You want one query.

We moved every log line to structured JSON with these fields:

correlation_id — uniquely identifies a patient message across all services
tenant_id — which hospital/clinic
resource_type — Patient, Observation, etc.
event — what just happened
duration_ms — how long it took
outcome — success / failure / partial

One query against our log store told us which tenant, which resource, which step, what went wrong. MTTR (mean time to recovery) for incidents dropped from ~40 minutes to ~8.

Lesson 6: PII logging will get you in trouble

You will not log patient names. You will not log SSNs / Aadhaar numbers. You will not log diagnoses. Period.

What you can log:

Resource type, resource ID hash, tenant ID
Timestamps, durations, outcomes
Sanitized field-presence (e.g., "had_address=true", not the address)

We added a pre-commit hook that scanned every PR for "obvious PII leak" patterns. Caught 2 leaks before they shipped.

Lesson 7: The on-call rotation is the best teacher

Six months into my role, my manager added me to on-call rotation. I was nervous. It was the single best decision for my engineering growth.

You learn things on-call you cannot learn anywhere else:

What your system actually does at 3am
Which logs are useful and which are noise
Which alerts are signal and which are noise
How a small bug in deployment becomes a customer-impacting incident in 12 minutes

If your role lets you opt into on-call, do it. It's the fastest engineering compounding you can get.

The compounding effect

After 15 months at IHX, I wasn't just "the Spring Boot guy from Masai." I was someone who'd debugged production at 2am, understood SLOs, had a feel for trade-offs between consistency and availability. That changed everything about how I approached engineering interviews afterwards.

It's also why I now work on integration platforms at AlignBits — the patterns are the same. Different domain, same engineering rules.

If you're starting in healthcare backend

Read the HAPI FHIR docs. The 80% you need fits in a weekend.
Get familiar with one EHR's API (Epic FHIR sandbox is free).
Pick a real test fixture set. Synthea generates realistic FHIR data.
Get on a real on-call rotation as soon as you can.
Find a senior engineer who'll review your code line-by-line. Mine made me 3x as good in 6 months.

Shubham Bhati is a Backend Engineer at AlignBits LLC. Previously Associate Software Engineer at IHX Private Limited working on FHIR-standard healthcare backend systems. Based in Gurgaon, India. Portfolio · GitHub · LinkedIn

Publishing checklist:

[ ] Cover image: abstract flow diagram or HL7 FHIR logo
[ ] Tags: #java #springboot #healthcare #fhir #hapifhir #backend #productionengineering #microservices
[ ] Add a "FHIR resources" link section at the bottom for SEO
[ ] Cross-post to Dev.to and Hashnode after 24h

Spring Boot REST API Best Practices in 2026: A Production Guide

Shubham Bhati — Sat, 16 May 2026 20:36:08 +0000

Published 2026-05-17 by Shubham Bhati — Backend Engineer (Java 17, Spring Boot, Microservices).

We've all been there - stuck with a slow and unresponsive Spring Boot REST API in production, wondering where it all went wrong. Recently, we encountered a similar issue with one of our APIs, where the average response time was over 500ms. After digging into the code, we realized that we weren't following some of the essential Spring Boot REST API best practices. In this article, we'll share our experience and provide a comprehensive guide on how to build production-grade REST APIs using Spring Boot.

Introduction to REST API Design
Choosing the Right HTTP Methods
Error Handling and Logging
Database Schema Design
Common Mistakes
Security Considerations
FAQ
Conclusion

Introduction to REST API Design

When designing a REST API, it's essential to keep in mind the principles of RESTful architecture. This includes using HTTP methods (GET, POST, PUT, DELETE) to interact with resources, using meaningful resource names, and handling errors properly. We've found that using a tool like Postman can be incredibly helpful in testing and debugging our APIs. For example, let's consider a simple API that returns a list of users:

@RestController
@RequestMapping("/users")
public class UserController {
    @GetMapping
    public List<User> getUsers() {
        return userRepository.findAll();
    }
}

In this example, we're using the @GetMapping annotation to map the /users endpoint to the getUsers() method, which returns a list of users.

Choosing the Right HTTP Methods

Choosing the right HTTP method for your API endpoint is crucial. For instance, if you're creating a new resource, you should use the POST method. If you're updating an existing resource, you should use the PUT method. We've seen cases where using the wrong HTTP method can lead to unexpected behavior and errors. For example, let's consider an API that creates a new user:

@PostMapping
public User createUser(@RequestBody User user) {
    return userRepository.save(user);
}

In this example, we're using the @PostMapping annotation to map the /users endpoint to the createUser() method, which creates a new user.

Error Handling and Logging

Error handling and logging are critical components of a production-grade REST API. We've found that using a combination of try-catch blocks and logging frameworks like Logback can be incredibly effective in handling errors and logging important information. For example, let's consider an API that handles errors:

@GetMapping
public List<User> getUsers() {
    try {
        return userRepository.findAll();
    } catch (Exception e) {
        logger.error("Error fetching users", e);
        throw new RuntimeException(e);
    }
}

In this example, we're using a try-catch block to catch any exceptions that occur when fetching users, and logging the error using Logback.

Database Schema Design

Database schema design is another critical aspect of building a production-grade REST API. We've found that using a tool like Hibernate can be incredibly helpful in designing and managing our database schema. For example, let's consider a simple database schema:

CREATE TABLE users (
    id INT PRIMARY KEY,
    name VARCHAR(255),
    email VARCHAR(255)
);

In this example, we're creating a simple table called users with three columns: id, name, and email.

Common Mistakes

Here are some common mistakes to avoid when building a Spring Boot REST API:

Not using meaningful resource names
Not handling errors properly
Not using the right HTTP methods
Not logging important information
Not securing your API properly

Security Considerations

Security is a critical aspect of building a production-grade REST API. We've found that using a combination of authentication and authorization mechanisms, such as OAuth and JWT, can be incredibly effective in securing our APIs. For example, let's consider an API that uses JWT to authenticate users:

@GetMapping
public List<User> getUsers(@RequestHeader("Authorization") String token) {
    // Verify the token and authenticate the user
    return userRepository.findAll();
}

In this example, we're using the @RequestHeader annotation to get the Authorization header, which contains the JWT token.

FAQ

What is the best way to handle errors in a Spring Boot REST API?

We've found that using a combination of try-catch blocks and logging frameworks like Logback can be incredibly effective in handling errors and logging important information. For more information, check out the Spring documentation.

How do I secure my Spring Boot REST API?

We've found that using a combination of authentication and authorization mechanisms, such as OAuth and JWT, can be incredibly effective in securing our APIs. For more information, check out the OAuth documentation.

What is the best way to design a database schema for a Spring Boot REST API?

We've found that using a tool like Hibernate can be incredibly helpful in designing and managing our database schema. For more information, check out the Hibernate documentation.

How do I choose the right HTTP methods for my Spring Boot REST API?

We've found that choosing the right HTTP method depends on the specific use case and the resources being interacted with. For more information, check out the RFC documentation.

Conclusion

In conclusion, building a production-grade Spring Boot REST API requires careful consideration of several factors, including REST API design, error handling and logging, database schema design, security considerations, and more. By following the best practices outlined in this article, we can build fast, scalable, and secure APIs that meet the needs of our users. For more information, check out the Spring Boot documentation.

From B.Com to Backend Engineer: My Masai School Journey

Shubham Bhati — Sat, 16 May 2026 17:58:53 +0000

From B.Com to Backend Engineer: My Masai School Journey

By Shubham Bhati — Backend Engineer at AlignBits LLC

The unlikely path

I have a Bachelor of Commerce degree from Devi Ahilya Vishwavidyalaya in Indore. Three years later, I'm a Software Engineer at an iPaaS company, shipping production Java microservices that integrate enterprise systems.

In between those two facts is one institution that changed my trajectory: Masai School.

This is the honest version of how I went from balance sheets to backend systems — what worked, what was hard, and what I'd do differently.

Why a B.Com grad picks up Java

I didn't grow up writing code. My undergrad was accounting, taxation, business law. By the final year of B.Com (2022), I had a clear realization: the work I was being prepared for didn't excite me. The work that did — building software — required skills my degree never gave me.

I had two options:

Spend ₹4–8 lakh on a Master's degree
Find a focused, intensive program that taught backend engineering for software jobs

I picked option 2 and applied to Masai School for their Software Engineering — Java Backend Specialization (then a 30+ week program in Bengaluru).

What Masai actually teaches

Forget the marketing. What I actually learned, in order:

Phase 1 — Foundations (HTML/CSS/JS, DSA)
Surprisingly tough. As a non-engineering grad, the first month was just adapting to "thinking like a programmer" — abstraction, recursion, big-O.

Phase 2 — Java + OOP
Where the Java backend specialization really started. Generic types, collections framework, exception handling, multithreading basics.

Phase 3 — Spring Boot + databases
The career-defining phase. REST APIs, Spring Data JPA, Hibernate, MySQL. By week 18, I was building functional CRUD APIs.

Phase 4 — Production-grade
Spring Security, JWT, OAuth 2.0, microservices patterns, message queues (RabbitMQ basics).

Phase 5 — Capstone projects
Real, deployable projects. Mine included Chatterbox (Spring Boot WebSockets) and a Shopzilla e-commerce backend.

What worked

1. Showing up every day
Masai is intense — 9–10 hours of focused work, six days a week. The students who showed up consistently are the ones who got hired. Talent matters less than this.

2. Building things outside class
I built side projects on weekends. SnapResize, TIC_TAC_TOE with JavaFX, and WorkFolio — these became my real portfolio.

3. Studying production code
Reading open-source Spring projects taught me more than tutorials ever did.

4. Practicing Java interview problems daily
HackerRank, LeetCode (easy/medium). I have an Intermediate badge for Java on HackerRank — earned by daily practice.

What didn't work (or what I'd change)

1. Spreading too thin
I tried to learn React + Java backend simultaneously in the first months. Mistake. Going deep on one stack beats being mediocre at two.

2. Skipping system design early
Masai covers basics, but interview-grade system design (LB, caching, partitioning, CAP, consistent hashing) — I learned that mostly on the job after joining IHX. Should have started earlier.

3. Not building public presence
I waited until job-search stage to make a GitHub portfolio. Should have been pushing code from week 1. Recruiters search GitHub more than they admit.

What happened after Masai

IHX Private Limited (Jun 2023 – Aug 2024) — Associate Software Engineer on healthcare backend systems. FHIR-standard integrations. This is where I learned production engineering: incidents, on-call, monitoring, SLOs.

AlignBits LLC (Sep 2024 – present) — Software Engineer on an iPaaS platform. Microservices at scale, message queues, AWS, cross-system integrations. Got promoted from Jr. in my first year.

In two years from graduating Masai I've:

Resolved 15+ production incidents
Managed 10+ client integration pipelines
Earned 25+ certifications (AI Engineer, Java, Prompt Engineering)
Stayed at backend engineering — never had to pivot

Is Masai worth it?

Honest answer: yes, conditionally.

It's worth it if:

You're committed to backend engineering as a career
You can dedicate 9+ hours/day for 30+ weeks
You have no engineering background and need structured fundamentals
You're OK with the pay-after-placement model (you don't pay until you're earning)

It's NOT worth it if:

You're looking for a credential to put on a resume without doing the work
You already know Java and Spring well — you'll be bored in the first half
You can't commit full-time

What I'd tell a B.Com student today

Pick one stack, go deep. Don't be a full-stack jack-of-all-trades. Java + Spring Boot is a solid bet for India in 2026.
Push code to GitHub from day one. Even bad code. Recruiters notice consistency.
Get a working website. Mine is at shubh2-0.github.io. It pulls more recruiter messages than my LinkedIn.
Solve 1 LeetCode problem a day. Not 10. One, every day, for a year.
Find a community. I'd struggled alone for months before joining Masai. Don't.

What's next

I'm currently exploring backend engineering roles — remote, hybrid, or relocation — with companies building products that scale. If you're hiring or know someone who is, my LinkedIn is the fastest way to reach me.

If you're a B.Com student staring at a coding bootcamp wondering if it's worth it: it is, if you do the work.

Shubham Bhati is a Backend Engineer at AlignBits LLC, working on iPaaS platform integrations with Java, Spring Boot, and AWS. Based in Gurgaon, India. Portfolio · GitHub · LinkedIn

Publishing checklist:

[ ] Add 2-3 images (Masai campus photo, your code screenshot, a system diagram)
[ ] Cover image: 1200x675 px (Canva)
[ ] Tags: #masaischool #javadeveloper #careerchange #bcomtocoding #backenddeveloper #java #springboot #india
[ ] Add canonical link back to your bio site
[ ] Cross-post to Dev.to and Hashnode after 24h (Medium gets first crawl)

Forem: Shubham Bhati

Calling OpenAI from Spring Boot: A Production-Ready Integration

Introduction to OpenAI API

Setting up OpenAI with Spring Boot

Creating a Service to Handle OpenAI Requests

Error Handling and Logging

Performance Optimization

Common Mistakes

FAQ

What is the OpenAI API?

How do I integrate OpenAI with Spring Boot?

What is the difference between Spring AI and OpenAI?

Can I use OpenAI with Java?

Conclusion

Further Reading

15 Production Incidents in a Healthcare Backend: FHIR Lessons

15 Production Incidents in a Healthcare Backend: What FHIR Taught Me About Reliability

What FHIR is (in 60 seconds)

What "production" means in healthcare

Lesson 1: Schema validation is not optional

Lesson 2: Idempotency or death

Lesson 3: The clock is not your friend

Lesson 4: Don't trust the network — design for partial failure

Lesson 5: Logging structure matters more than log volume

Lesson 6: PII logging will get you in trouble

Lesson 7: The on-call rotation is the best teacher

The compounding effect

If you're starting in healthcare backend

Spring Boot REST API Best Practices in 2026: A Production Guide

Introduction to REST API Design

Choosing the Right HTTP Methods

Error Handling and Logging

Database Schema Design

Common Mistakes

Security Considerations

FAQ

What is the best way to handle errors in a Spring Boot REST API?

How do I secure my Spring Boot REST API?

What is the best way to design a database schema for a Spring Boot REST API?

How do I choose the right HTTP methods for my Spring Boot REST API?

Conclusion

Further Reading

From B.Com to Backend Engineer: My Masai School Journey

From B.Com to Backend Engineer: My Masai School Journey

The unlikely path

Why a B.Com grad picks up Java

What Masai actually teaches

What worked

What didn't work (or what I'd change)

What happened after Masai

Is Masai worth it?

What I'd tell a B.Com student today

What's next