Test in Postman

Postman is an API platform that allows you to build, send, and inspect HTTP requests to test API workflows. You can use Postman to validate OAuth credentials, simulate Patient360 queries, and confirm connectivity to the selected environment.

To get started, import the Postman collection, configure the required variables, and run the key test requests.

Prerequisites

Download and install Postman from http://postman.com
Request the Health Gorilla Postman collection file from your Client Success Manager (CSM)
Download the collection file from your implementation resources

To import and configure the collection

In Postman, from the main menu, select Import.
Upload the Health Gorilla Postman collection file.
In the left sidebar, under Collections, select Health Gorilla API.
On the right, select Variables and enter this information.

clientId: Your OAuth client ID
client_secret: Your OAuth client secret
client_uri: Your OAuth client URI
jwt_sub: The user subject from your OAuth configuration

Select Reset All, then click Save.

To run the test requests

Use the steps below to validate your Patient360 workflow in Postman. Each request confirms part of the data flow, from authentication through record retrieval and FHIR search. The troubleshooting column helps resolve common issues.

Step	To	Do this	Expected Response	Troubleshooting
1	Exchange your OAuth credentials for an access token	Select 1. Get JWT and Get Access Token, then click Send	`200 OK` with a valid `access_token` and `expires_in`	Token is missing, expired, or invalid → Check OAuth variables and authorization server
2	Register a patient in your environment	Select 2. Create a Patient, then click Send	`201 Created` with a new `Patient.id` in the `Location` header	Required fields are missing or improperly formatted → Review request body
3	Use the `$cw-search` operation to check for patient matches in external networks	Select 3. Search for Patient Matches, then click Send	`200 OK` with a `Bundle` containing external `Patient` entries	No matches found or patient not fully specified → Verify identifiers and demographics
4	Link a matched external identity to your patient using `$cw-enroll`	Select 4. Enroll Patient, then click Send	`200 OK` with an `OperationOutcome` or confirmation message	Match not selected or ID mismatch → Check patient references and rerun `$cw-search`
5	Initiate a Patient360 retrieval using `$p360-search` and `Prefer: respond-async`	Select 5. Query Networks for Medical Records, then click Send	`202 Accepted` if asynchronous, `200 OK` with a `Bundle` if synchronous	Patient not enrolled or request not properly formatted → Confirm `$cw-enroll` was successful and headers are correct
6	Store the returned records using `POST /Bundle`	Select 6. Import Retrieved Records, then click Send	`200 OK` or `201 Created` with a success message	Invalid resource types or malformed bundle → Inspect payload structure
7	Retrieve additional structured data such as Observations or Conditions	Select 7. Search for FHIR Resources, then click Send	`200 OK` with a `Bundle` of matching entries	No data found or query filters incorrect → Confirm patient ID and verify data exists

Common API response codes

200 OK: Request succeeded
201 Created: Resource was successfully created
202 Accepted: Request has been accepted for processing, but the operation has not completed
401 Unauthorized: Token is missing, expired, or invalid
404 Not Found: No records were returned; the requested resource does not exist or search yielded no results

Conclusion

By completing this test workflow, you confirm that:

Your OAuth configuration is correct and tokens are being issued
You can create and manage patient records within your tenant
Patient360 identity matching and data retrieval are functioning as expected
Your system is capable of ingesting and querying structured FHIR data

Your environment is ready for continued development or production onboarding.