Centralizing HTTP Requests in Neutrinos SSD
Managing HTTP requests in Neutrinos SSD can quickly become messy if each API call has its own request node and response logic. A better approach is to centralize your HTTP handling. Here’s how 
Folder Structure
Folder StructureUnder the util folder, create a new SSD flow named:
http
This flow should:
- Accept a generic request object
bh.local.reqObject = {
method: 'POST', // HTTP method: 'GET', 'POST', 'PUT', 'DELETE', etc.
url: 'https://api.example.com/data', // Target API endpoint
payload: { } // Request body (for POST, PUT) ,
headers: { // Optional: custom headers
'Content-Type': 'application/json',
Authorization: 'Bearer <token>'
},
isMock: false, // Set to true to return a mock response
};
- Use a Switch node to check whether it’s a live API call or a mock
- Route the flow accordingly:
→ If mock is required (e.g., testing, API not yet available), return a mock response
→ Otherwise, make an actual HTTP call
Why This Is a Best Practice?
Why This Is a Best Practice?
Improved Debugging
All your API requests and responses go through a single point. Makes logging and debugging a breeze.
Easier Testing with Mocks
For projects in early stages or backend delays, easily enable mock responses by just setting a flag in your request.
Cleaner Codebase
No need to create multiple similar HTTP Request nodes across your SSDs. Just call the centralized flow.
Flow Entry → 
Switch → 
Mock Response / 
HTTP Request → Script
This structure helps decouple mock vs real logic at one place.
Let me know if you want the reusable flow snippet or want to contribute to the series with your own patterns!
#Neutrinos #SSD #BestPractices #APIDesign #MockTesting
