Private corporate batches, live online cohorts and 1-on-1 mentoring in API request design, collections and environments, scripted assertions, and Newman-driven API regression in CI — taught by a practitioner who runs it in production.
20 years across DevOps, SRE and Security · 10,000+ engineers trained · Trained teams at JPMorgan Chase, Verizon, Nokia and the World Bank
Principal DevOps Engineer & Architect
Rajesh teaches Postman as API test engineering rather than a tour of the interface: variable scope and resolution order, request chaining through pre-request and test scripts, schema-based assertions instead of brittle string matching, and Newman running the same collection in a pipeline with reports the build can gate on. Sessions cover the parts that decide whether a collection survives a team — collection structure and version control, environment and secret hygiene, data-driven runs, mock servers and OpenAPI alignment, and the authorisation flows that break unattended execution. Twenty years across DevOps, SRE and Security and 10,000+ engineers trained inform the pipeline and governance decisions.
Twenty years across DevOps, SRE and Security, in principal and architect roles at PayPay, SoftwareAG, ServiceNow, JDA Software, Intuit, Adobe and others. He has trained engineers at JPMorgan Chase, Verizon, Nokia, the World Bank, VMware, Oracle, Mercedes-Benz and Airbus — more than 10,000 people personally. He teaches what he runs, not what he reads.
You are booked with a named engineer, and that is who turns up. Marketplaces and larger providers rotate whoever is free, so the person who sold you the agenda is rarely the person teaching it.
The same trainer is available for the next engagement, which matters when a team builds on what it learned last time.
Your batch is assigned a named trainer before it starts, and that is who teaches it. See the full faculty.
Engagements are matched on the tool, not the calendar. For Postman that means a trainer who has run it in production — API request design, collections and environments, scripted assertions, and Newman-driven API regression in CI — rather than whoever is free that week. You are told who is teaching before you commit, and that person is on the discovery call that shapes the agenda.
Where a batch is large enough to need a second trainer, the pairing is declared up front. The lead trainer stays accountable for the syllabus and the assessment either way.
Principal DevOps Engineer & Architect
Twenty years across DevOps, SRE and Security in principal and architect roles at PayPay, SoftwareAG, ServiceNow, JDA Software, Intuit, Adobe, IBM/Emptoris, Ness, MindTree and Accenture. He has trained more than 10,000 engineers personally, at organisations including JPMorgan Chase, Verizon, Nokia, the World Bank, VMware, Oracle, Mercedes-Benz and Airbus. He teaches what he runs, not what he reads.
Teams of 8–30
Custom agenda, your timezone, onsite or online, NDA-friendly.
Request a quoteIndividual engineers
A private instructor and a curriculum built around your goal.
₹99,999Individuals who want peers
Scheduled batch, max 8 to 10 hours of live instruction.
₹34,999A private batch starts with a discovery call. We look at the stack you actually run — the CI system, the cloud, the constraints — and map the agenda onto it, so examples use your topology rather than a generic one.
Delivery is onsite at your premises, live online, or hybrid, scheduled around your release calendar rather than ours. Batches run 8 to 30 engineers.
Every attendee leaves with recordings, slides, lab repositories and a completion certificate. You receive an attendance and assessment report. Invoicing supports PO and GST.
Talk to us about a private Postman batchPostman is an API platform for designing, sending, documenting and testing HTTP requests. Its object model is small and everything else builds on it: a request carries a method, URL, headers, body and authorisation; requests are organised into collections and folders; variables resolve from a layered set of scopes; and each request can run a pre-request script before it is sent and a test script after the response arrives. Those scripts execute in a JavaScript sandbox with the pm API, so `pm.test`, `pm.expect`, `pm.response` and the variable setters turn what looks like a manual request tool into an executable regression suite.
The features that matter in a real team sit around that core. Environments hold per-stage configuration so the same collection runs against local, staging and production. The Collection Runner executes an ordered set of requests, optionally iterating over a CSV or JSON data file, which is how a single request becomes a data-driven test. Authorisation helpers cover Basic, Bearer, API key, OAuth 2.0 and AWS Signature so token acquisition stops being hand-rolled. Mock servers return example responses before a backend exists, monitors run a collection on a schedule from Postman's infrastructure, and OpenAPI import keeps a collection aligned with a specification instead of drifting from it.
Newman is what makes Postman a pipeline tool rather than a desktop one. It is the command line collection runner: the same collection, environment and data file executed in CI, emitting JUnit XML, HTML or JSON reports that a build system can gate on. That is also where Postman's main failure mode shows up — collections that live only in a shared workspace become untracked shared state, and exported environments leak secrets into version control. The disciplined pattern is to keep collections in Git, keep secrets out of them, and run them with Newman on every build.
Almost every system is now assembled from APIs, and the API layer is where integration defects actually live. Contracts change, a field becomes nullable, a status code changes from 200 to 202, an authorisation scope is tightened — and none of it is visible from a user interface test until something downstream breaks in production.
API testing is also the highest-leverage layer in a test suite. An API test runs in milliseconds where a browser test takes seconds, it is deterministic where a UI test is timing-dependent, and it localises failure to a single endpoint. Teams that move checks down from the browser layer to the API layer routinely cut pipeline time by an order of magnitude while catching more, and Postman is the shortest path there because the same tool used to explore an endpoint by hand produces the automated test.
The demand is for the engineering half rather than the clicking half. Sending a request is not a skill. Designing a collection that runs unattended across four environments, chaining authentication and resource creation through variables, asserting against a JSON schema rather than a hard-coded string, keeping secrets out of exported files, and running the whole thing in a pipeline with reports a build can fail on — that is what organisations are hiring and training for.
The protocol before the tool. Methods and their semantics, status code families and what each actually promises, headers that change behaviour, content negotiation, idempotency and caching. Then Postman's own objects — workspace, collection, folder, request, example, environment — and how they relate.
Topics: HTTP methods, safety and idempotency · Status code families and the ones people misuse · Headers, content types and content negotiation · REST conventions, resources and versioning · Workspaces, collections, folders and requests · Saved examples and their role in documentation and mocks · The Postman console and reading the raw exchange
Everything that goes into a request. Query and path parameters, the body formats that trip people up — raw JSON, form-data, urlencoded, binary and GraphQL — and the authorisation helpers, ending with the OAuth 2.0 flows that decide whether a collection can run unattended in CI.
Topics: Path, query and header parameters · Request bodies: raw JSON, form-data, urlencoded, binary, GraphQL · File uploads and multipart requests · Basic, Bearer and API key authorisation · OAuth 2.0 grant types and which ones automate cleanly · AWS Signature and other signing helpers · Cookies, sessions and the cookie jar · Certificates, proxies and TLS troubleshooting
Where a collection stops being a list of requests. The five variable scopes and their resolution order, dynamic variables, the pre-request script, and using the test script to extract values from a response and feed them into the next request. Then control flow with setNextRequest, and the sendRequest helper for out-of-band calls.
Topics: Variable scopes: global, collection, environment, data, local · Resolution order and diagnosing the wrong value · Dynamic variables and generated test data · Pre-request scripts and computed values · Extracting response values into variables · Request chaining: token, create, read, update, delete · postman.setNextRequest and conditional flow · pm.sendRequest for setup calls outside the main flow
Test design rather than syntax. The pm API and the Chai assertion style, asserting on structure with JSON schema instead of on exact strings, response time budgets, header and status assertions, negative and boundary cases, and the failure messages that make a red run diagnosable at a glance.
Topics: pm.test, pm.expect and the Chai assertion style · Status, header, body and response time assertions · JSON schema validation with ajv · Asserting on structure rather than exact values · Negative testing: bad input, missing auth, wrong content type · Error handling and skipping tests conditionally · Readable failure messages and test naming · The visualizer for response rendering
Moving from manual execution to unattended execution. The Collection Runner with iterations, delays and data files; then Newman — installation, arguments, environment and data injection, reporters, exit codes — and wiring it into a pipeline so a failed assertion fails the build.
Topics: Collection Runner: order, iterations, delays and persisted variables · Data-driven runs from CSV and JSON · Newman installation and command line arguments · Injecting environments, globals and data files at run time · Reporters: CLI, JUnit XML, HTML and JSON · Exit codes and failing a build correctly · Running Newman in a container · Pipeline integration and publishing reports as artefacts
Using Postman before and after the code exists. Mock servers built from saved examples so a client team can start immediately, monitors that run a collection on a schedule as a lightweight synthetic check, and OpenAPI import and generation so the collection tracks the specification instead of drifting away from it.
Topics: Saved examples and mock server behaviour · Matching rules and mock response selection · Contract-first workflow with an OpenAPI specification · Generating a collection from a specification and keeping them in sync · Monitors: scheduling, regions, alerts and their limits · Using monitors as a synthetic availability check · API documentation generated from the collection · Where Postman stops and a dedicated contract-testing tool starts
The organisational half, and the part that causes incidents. Workspaces and access, forking and merging collections, version control in Git rather than only in a shared workspace, keeping tokens and passwords out of exported environments, and the review discipline that stops a collection becoming untracked shared state.
Topics: Workspaces, roles and collection sharing · Forks, pull requests and merging collection changes · Exporting collections and environments into Git · Secrets: what must never sit in an exported environment · Secret variable types, vault integration and CI-injected credentials · Naming, structure and review conventions for a team · Environment promotion across local, staging and production · Handing a collection over to another team
We rebuild the agenda around the tools you actually run.
Request a custom agendaAcquire an OAuth token, create a resource, read it back, update it and delete it — passing every identifier through variables, with assertions at each step.
Replace exact-value assertions with JSON schema validation across a collection, then change a field type on the server and prove the suite catches it.
Drive one endpoint from a CSV of valid, invalid and boundary inputs, and produce a report that identifies exactly which rows failed and why.
Run the collection with Newman from a pipeline, inject the environment and credentials at run time, publish JUnit and HTML reports, and fail the build on a real defect.
Build a mock server from saved examples, develop a client against it, then swap in the real service and confirm the collection still passes unchanged.
Move collections into Git with review, strip secrets from environments, define naming and structure conventions, and wire the whole thing into a pipeline stage.
Billed yearly at ₹9,996
Max 8 to 10 hours of live instruction
Full program, private instructor
8–30 engineers · custom agenda · onsite or online · PO and GST invoicing
Refunds. If we cancel or postpone a cohort, you get a full refund within 15 days. There is no money-back guarantee otherwise.
Terms. Course material remains licensed to the attendee. Read the terms.
Your data. We don't share it with third parties. Privacy policy.
Certificate of completion
Basics explanation was exemplary from Rajesh where he dealt with complicated topics to be simple. Great learning stuff personally for me.
Very detailed explanation and has lots of patience in attending the questionnaire. Thanks again for your wonderful sessions.
Good discussion, helped us to understand different tools in SRE.
Got good lab sessions which kept the new DevOps tool learnings to the point and it helped a lot in my career.
I took Terraform training with the tutor named Mithilesh. I requested to tailor the course curriculum for my needs. He did an excellent job of showing me how to write the Terraform script per the instructions provided.
My experience with the AIOps training was positive. The course covered important topics in a structured way, and Rajesh Kumar explained the concepts patiently. I found the practical aspects particularly helpful because they made the technical content easier to understand.
| What matters | YouTube + blogs | Generic online course | Freelance marketplace | DevOpsSchool |
|---|---|---|---|---|
| Named practitioner | No | Rarely | Varies per booking | Yes — same trainer each time |
| Production experience | Unknown | Unknown | Unverified | 20 years, named employers |
| Custom agenda | No | No | Sometimes | Built from your stack |
| Onsite delivery | No | No | Sometimes | Yes |
| Lab environment | None | Sandbox that expires | Varies | Your own cloud — skill goes with you |
| Assessment | None | Quiz | Rarely | Assignments + capstone per module |
| Per-attendee certificates | No | Sometimes | Rarely | Yes |
| Corporate invoicing | No | Limited | Varies | PO and GST |
| Post-training support | None | Forum, time-limited | None | Lifetime forum access |
Tell us the team, the stack and the timeline. You'll get a straight answer, not a sales sequence.
Talk to an advisorPrefer to call or email?
More ways to reach us on the contact page.