Map HOYTS API Traffic in Postman

Map and sanitize HOYTS food-ordering API traffic in a Postman collection.

Introduction

30 Second Summary

Ordering food online can look like one simple click. Behind the screen, the page exchanges many messages as you move from a menu toward checkout.

In this project, you will map one normal HOYTS food-ordering journey to the HTTP requests behind it. You will turn your findings into a sanitized Postman collection of manually verified read-only calls.

What You'll Build

You demonstrate one cinema ordering journey in Postman's Browser Tool while your collection reveals the safe public retrieval calls behind each click.

By the end of this project, you'll have:

A visual flow map you can use to explain which network request follows each cinema or menu click.
A sanitized read-only collection that lets you manually replay public retrieval calls without carrying private session values.
Reusable local collection variables that keep stable non-sensitive values in one place for future manual checks.
Secret Mission: Compare menu traffic for a second cinema to identify stable request components and cinema-specific values.

Are there any prerequisites?

You need the Postman desktop app on Windows, a free Postman account, and basic familiarity with HTTP methods, headers, and responses. The guide stops before payment and does not assume that account-gated HOYTS screens are available.

Before We Start

Before any traffic is captured, this checkpoint locks in a clear learning goal and a strict production-safety boundary. You are mapping one normal HOYTS ordering journey for personal learning, replaying only manually verified read-only calls, entering no payment details, and submitting no order.

Set Up a Safe Postman Workspace

Captured production HTTP traffic can include private session values. It can also include actions that change a real cart.

A writable Postman workspace gives your map a controlled home. Clear guardrails limit every replay to a manually verified read-only request.

In this step, get ready to:

Prepare a writable Postman workspace.
Create the guarded Postman collection with its read-only folder.
Verify the Postman Browser Tool capture views.

Open Postman in a writable workspace

Postman requires an account before you can create a collection. A writable workspace lets you edit the collection throughout the project.

Account access can feel sensitive because this project deals with captured traffic. Your account details stay inside Postman's own sign-in flow.

Press the Windows key to open the Windows search bar.
Type Postman into the search bar.
Press Enter to open the installed desktop app.

You'll see the Postman desktop app open on Windows.

Follow Postman's account prompt to sign in or create a free account.

Postman returns you to its workspace interface after account access succeeds.

Use the workspace selector to choose a workspace where collection creation controls are available.
Confirm that the selected workspace lets you create collections.

That is your first safety check complete. The workspace can now hold editable project records.

Can't Access a Writable Workspace?

Complete Postman's sign-in prompt if it reappears.
Select another workspace where collection creation controls are available.

If access still fails, help me resolve a Postman sign-in or workspace access issue.

Create the guarded collection

A collection groups the requests that belong to one learning workflow. Its Overview description records the boundary that every saved request must follow.

Use the collection creation control under Collections.
Enter HOYTS Food Ordering Flow - Read Only as the collection name.
Complete the form to create the collection.

You'll see HOYTS Food Ordering Flow - Read Only under Collections.

Select HOYTS Food Ordering Flow - Read Only under Collections.
Open the collection's Overview tab.

The Overview needs these five guardrails:

One manual browser journey.
No payment details.
No final order submission.
No Collection Runner or monitor against HOYTS.
Only individually verified read-only replays.

Add all five guardrails above to the Overview description.
Save the collection description using the available save control.

You'll see all five guardrails recorded in the collection Overview.

Use the collection's folder creation control to add 01 Read-Only Replay.
Confirm that 01 Read-Only Replay appears inside the collection.

Good progress. Your collection now separates future verified replays from every request that stays documentation-only.

Why Establish Guardrails Before Capture?

The collection rules keep this project focused on one manual learning journey. They also prevent captured cart or checkout traffic from becoming reusable requests.

The read-only folder has a strict entry test. A request belongs there only after sanitization confirms that one manual replay still returns its intended public content.

Open the Browser Tool and verify the setup

The Browser Tool records requests in the Network tab. It records page actions in the Interactions tab.

Before you use the shortcut, which two capture views do you expect to find?

Open the Browser Tool by pressing Ctrl + Shift + B in Postman.

The Browser Tool opens with the Network tab available. You'll also see the Interactions tab.

Why Use the Browser Tool?

The Browser Tool keeps request records beside their corresponding browser interactions in Postman. This makes each deliberate click easier to match with its network traffic.

The Browser Tool maintains its own cookies independently of the main Postman session. Later sanitization checks whether a captured request still works without those session values.

Confirm that HOYTS Food Ordering Flow - Read Only remains visible under Collections.
Confirm that the Network tab has no relevant HOYTS capture retained yet.

Your Browser Tool is ready without any HOYTS order traffic or executable captured request.

Browser Tool Not Opening?

Return to the Postman desktop app before trying the shortcut again.
Select Tools in the Postman footer.
Select Browser to open the Browser Tool.

If the capture views are still missing, help me open Postman's Browser Tool on Windows.

This checkpoint shows only workspace structure. It does not need to include account credentials or private session data.

Your safety rules and capture workspace are ready. Next, you'll reveal the traffic behind one deliberate browser action.

Reveal Requests Behind Order Now

Your safe workspace is ready. Now you can use the Postman Browser Tool to connect one visible HOYTS action to the HTTP traffic it creates.

A page load creates a crowded capture because assets appear beside ordering traffic. Background requests add more noise.

In this step, get ready to:

Load the HOYTS food page to reveal the raw capture noise.
Isolate one Order Now interaction across both Browser Tool tabs.
Inspect one relevant request in Browser Tool only.

Load the HOYTS food page

The Browser Tool's Network tab records the requests made during a page load. The first load gives you an unfiltered baseline.

Before you load the page, do you expect the capture to contain one ordering request or a mixture of browser traffic?

Switch back to the Browser Tool from earlier.
Select the Network tab.
Click the address field at the top of the Browser Tool.
Enter https://www.hoyts.co.nz/food-and-drinks.
Press Enter to load the page.

You will see many request rows during the load. This crowded first capture is the intended result.

Why Is One Click Hard to Spot?

Modern web pages fetch many resources during a load. Background requests can arrive at the same time.

A useful ordering request can therefore sit beside unrelated traffic. Interaction timing gives you a marker for finding it.

Page Not Loading?

Check that the address matches https://www.hoyts.co.nz/food-and-drinks.
Stop if HOYTS requires account access that you cannot complete normally.

Ask for help if you need it: help me load the HOYTS page in Postman Browser Tool.

Isolate the Order Now interaction

Older rows blur the moment when a deliberate action happens. A fresh capture gives the click a clear point in time.

Click Clear in the Network tab.

The previous request rows should disappear from the capture.

Reload the HOYTS page with the Browser Tool's reload control.

You will see a fresh set of page-load requests in the Network tab.

Click Order Now once on the HOYTS page.
Stop at any account-access prompt.
Select the Interactions tab.

You should see an entry reporting Clicked or Navigated around the moment of the action. The nearby request timing gives you a smaller group of rows to investigate.

What Do the Two Tabs Show?

The Network tab shows what the browser requested.
The Interactions tab shows what you did on the page.
The recorded timing lets you connect the page action to nearby requests.

Cannot Match the Interaction?

Confirm that you clicked Order Now inside the Browser Tool.
Use the recorded Time value to locate requests from the same moment.

Ask for help with the correlation: help me match a Browser Tool interaction to its Network requests.

Inspect one relevant request

One row becomes useful when its fields explain what the browser requested. Its response shows what the server returned.

Return to the Network tab.
Use the interaction's Time value to focus on nearby rows.
Select one row that appears connected to the page change.
Inspect the request URL.
Inspect the request parameters.

What Do the URL and Parameters Reveal?

The URL identifies the destination requested by the browser. Its path often points to the kind of content being requested.

Parameters carry extra values used to narrow a request. They can help you spot selections made through the interface.

Inspect the request headers.
Inspect the response status.
Inspect the response content.
Leave the captured request unsent.
Leave the captured request unsaved.

Why Keep This Request in Browser Tool?

Captured headers can carry session data. Viewing the request is enough to learn its structure at this stage.

The request remains an inspection record until a later safety check proves it can be replayed.

Before you compare the tabs one last time, do you expect the click's Time value to align with the nearby request activity?

Return to the Network tab.

Each request row should show a method. It should also show a URL.

Each row should show a status. It should also show a duration.

Select the Interactions tab.

You should see the corresponding click or navigation near the same time as the relevant request activity. At least one relevant row has now been inspected for its URL, parameters, headers, response status, and response content.

Request Details Still Unclear?

Return to the interaction's Time value.
Choose another row from the same time window.

Ask for help interpreting the fields: help me inspect this captured request safely.

You have your first browser-to-request correlation without sending or saving the capture. Next, you will map a normal ordering journey to its pre-payment boundary.

Map the Journey to Pre-Payment

Your first Order Now click exposed the HTTP requests behind one visible action in the Postman Browser Tool.

One isolated request cannot explain the full ordering journey. This step connects each normal browser action to the retrieval or state-changing traffic it triggers.

In this step, get ready to:

Capture one normal ordering journey through the pre-payment boundary.
Map every browser interaction to its associated network rows.
Classify each row as Replay or Observe only.

Capture one normal ordering journey

The Network tab mixes ordering calls with page assets and background traffic. The Interactions tab provides the timeline you need to separate meaningful requests from that noise.

Payment screens can feel like a risky boundary. Your stopping point is the furthest screen available before any payment detail or final submission.

Select the Network tab in the Browser Tool.
Click Clear to remove the earlier request rows.
Select the Interactions tab.
Click Clear to remove the earlier interaction records.
Return to the HOYTS ordering page from earlier.
Select one cinema through the currently displayed ordering flow.
Select one food item through the normal interface.
Continue to the cart screen.

Keep the boundary visible

Your capture now covers the browsing portion of the journey. The remaining screens reveal how cart and checkout activity changes the traffic.

Follow the currently displayed cart and checkout screens.
Leave any customer-detail fields empty.
Stop before entering payment details.
Stop before submitting the order.
Stop at an account-access prompt if the flow requires access you do not already have.

Before you inspect the completed capture, do you expect each visible action to match one neat request row?

Return to the Network tab.

You should see many Network rows around the small set of actions you performed. That capture noise is the intended shortfall you will solve with the interaction timeline.

Return to the Interactions tab.

You should see the cinema selection, food-item selection, cart navigation, and available checkout navigation recorded in sequence. No payment or final submission interaction should appear.

Missing part of the journey?

Keep the current capture if the ordering flow stopped at an account prompt or another access requirement. Your furthest available pre-payment screen is the correct boundary.

If an interaction is missing, repeat only that normal interface action after confirming the Browser Tool is still recording.

Ask for help if your capture does not match the actions you performed: help me compare my Postman Browser Tool Network and Interactions records

Build the redacted flow map

A flow map turns the capture into a timeline that someone else can follow. Redaction preserves useful request structure while removing private or session-specific values.

What each column captures

Browser action records the visible interface event that caused the traffic.
HTTP method records the method shown in the Network row.
Redacted host and path preserves the route structure without private, session, or cart values.
Status records the response status shown for the request.
Response content type records the format indicated by the response details.
Likely purpose describes the request's role based on the interaction and response.
Safety classification records either Replay or Observe only.

Switch back to the HOYTS Food Ordering Flow - Read Only collection from earlier.
Select the collection's Overview tab.
Place the flow-map table below the existing safety rules.
Add the seven column headings explained above.
Return to the Interactions tab.
Use each interaction's Time value to locate its surrounding Network traffic.
Inspect the relevant Network rows recorded around that time.
Redact private or session-specific URL segments before recording each row.

What must stay out of the map?

Request headers can carry credentials or session data through fields such as Cookie and Authorization. The flow map stores request metadata without copying those values.

Personal data, tokens, cart identifiers, and payment values also stay out of the Overview. Redaction keeps the artifact safe to revisit.

Add one redacted table row for each associated Network request.
Repeat the mapping process for every recorded interaction.
Save the collection Overview using Postman's save control.

You should now be able to follow the visible journey from cinema selection to the pre-payment boundary through the rows in your Overview.

Classify replay and observe-only traffic

A safe method has read-only semantics. A captured GET becomes a replay candidate only when cinema or menu browsing caused it.

Browser Tool keeps its own browser session separate from the main Postman session. Any request that appears dependent on that session stays documentation-only.

Apply the safety classifications

Replay applies only to cinema-browsing or menu-browsing GET calls.
Observe only applies to cart traffic.
Observe only applies to customer-details traffic.
Observe only applies to checkout traffic.
Observe only applies to payment traffic.
Observe only applies to order-submission traffic.
Observe only applies to any method other than GET.
Observe only applies to uncertain traffic.
Observe only applies to session-dependent traffic.
Observe-only entries remain redacted metadata without executable request copies.

Review each row in the collection Overview.
Enter Replay only for rows permitted by the classification rules.
Enter Observe only for every remaining row.
Scan the Overview for any private or session-specific values.
Select the 01 Read-Only Replay folder.
Confirm that no executable requests are listed in the folder.

The 01 Read-Only Replay folder should still be empty. Replay candidates remain classifications in the flow map until the next step sanitizes and tests them.

Before you perform the final check, do you expect every recorded interaction to have at least one fully classified flow-map row?

Return to the collection Overview.
Compare every Interactions entry with the corresponding flow-map rows.
Check that every row contains all seven required fields.
Check that every safety classification follows the rules above.

You should see every performed interaction connected to at least one fully documented row. Only cinema or menu GET rows should show Replay.

Every cart, customer-details, checkout, payment, order-submission, non-GET, uncertain, or session-dependent row should show Observe only. No payment or final order submission should appear in the interaction history.

You have turned noisy production traffic into a safe map of the full pre-payment journey. Next up, you will sanitize each replay candidate and keep only the requests that still return their intended public content.

Build and Verify Read-Only Replays

Your redacted flow map now separates cinema and menu GET candidates from every observe-only request.

Raw captured traffic can still carry private or session-bound values. This step turns each candidate into an individually verified read-only replay.

In this step, get ready to:

Save each replay candidate with its browser action and expected response.
Remove session-bound values before sending each candidate exactly once.
Replace verified stable values with local collection variables.

Save replay candidates with their purpose

The Postman Browser Tool opens captured traffic in a request editor. That editor exposes the captured URL plus its parameters.

This part can feel risky because temporary copies may contain live session values. You will remove those values before any request is sent.

Switch back to the Network tab in the Postman Browser Tool from earlier.
Use your collection Overview flow map to identify the first cinema or menu GET marked Replay.
Select the matching row in Network.

You should see an HTTP request containing the captured URL. Its parameters plus its headers are available for inspection.

Save the opened request to 01 Read-Only Replay.
Name the request after the browser action it supports.

The named request should now appear inside 01 Read-Only Replay.

Add a request description stating the expected non-personal response.
Repeat this save process for each remaining cinema or menu GET marked Replay.

Your replay folder should now contain only the candidates already approved by the redacted flow map. Every request name should point back to a browser action.

Unable to match a candidate?

Compare the request with the corresponding entry in Interactions. Save it only when the flow map already classifies that exact row as Replay.

Ask for help if the timing or purpose remains unclear: help me correlate a Postman Network request with its browser interaction.

Strip session data before testing

In HTTP, a GET requests a representation of a resource. A captured GET can still depend on cookies or credentials.

Why does a GET still need sanitizing?

Safe describes the intended semantics of the method. It does not prove that a captured request is public or reusable.

The Browser Tool keeps its own browser session. Removing session data tests whether the request can return its documented public content independently.

Select the first saved candidate in 01 Read-Only Replay.
Remove any Cookie header.
Remove any Authorization header.

The request headers should now show neither Cookie nor Authorization.

Remove any credential, token, personal, session, cart, or payment value from the request URL.
Remove any credential, token, personal, session, cart, or payment value from the request parameters.

The URL plus its parameters should now contain only values needed for the public cinema or menu action.

Remove any credential, token, personal, session, cart, or payment value from the remaining headers.
Remove any credential, token, personal, session, cart, or payment value from the request body.

The request editor should now contain no private or state-changing value.

Save the sanitized request.

Before you send this candidate, do you think it can still return its intended public content without the removed session values?

Send the selected request exactly once by selecting Send.
Compare the response with the expected response description.

A behind-the-scenes API request qualifies for replay only when its sanitized response still matches that documented purpose.

✔️ It returns the intended public data

That request passed the hard part. It now qualifies as a manually verified public read-only replay.

Keep the request in 01 Read-Only Replay.
Keep its flow-map classification as Replay.

ⓧ It no longer returns the intended data

This result shows that the captured request depended on removed session data. The failed replay still provides useful evidence for your flow map.

Delete the executable request from 01 Read-Only Replay.
Change its Overview classification to Session-dependent: observe only.
Keep only its redacted metadata in the Overview.

Apply this same sanitization and single-send check to each remaining saved candidate.

After every candidate has been tested, choose the path that matches the requests remaining in your folder.

✔️ A public API request survived

Keep only the requests that returned their documented public content. Every retained request should have been sent exactly once.

ⓧ No public API request survived

Session-bound traffic is common in ordering interfaces. Your flow map remains useful because it explains why those requests were excluded.

Return to the Network tab from earlier.
Locate the captured GET for https://www.hoyts.co.nz/food-and-drinks.
Select the matching request row.
Save the public page request to 01 Read-Only Replay.

The public page request should now appear as the only executable request in the replay folder.

Name the request after the public food-page browser action.
Add a description stating that the expected response is the public Food & Drink page content.

The request now has a name plus a non-personal expected response.

Remove any Cookie header.
Remove any Authorization header.

The baseline request should now show neither session header.

Remove any remaining credential, token, personal, session, cart, or payment value.
Save the sanitized baseline request.

The baseline should now contain only the public HOYTS page URL plus ordinary retrieval metadata.

Before you test the baseline, do you expect the public page to remain available without session data?

Send the baseline request exactly once by selecting Send.

You should receive public content matching the HOYTS Food & Drink page. This becomes your baseline read-only check.

Response purpose still unclear?

Compare the returned content with the request description. Exclude the request whenever the content is missing or its purpose remains uncertain.

Use the safe option when you cannot verify the result: help me decide whether this sanitized response matches its documented public purpose.

Add local variables and inspect the final collection

A collection variable replaces repeated text with one reusable value. Postman keeps collection variable values local unless you explicitly share them.

Select the HOYTS Food Ordering Flow - Read Only collection from earlier.
Open the Variables tab.
Select Add variable.
Enter base_url as the variable name.

You should see a new collection-variable row named base_url.

Enter the verified stable non-sensitive base URL used by the retained requests as its local value.
Keep the value local by leaving it unshared with the Postman cloud.

The local base_url row should now contain the stable URL prefix used by the retained request set.

Replace the matching base URL text in each retained request with {{base_url}}.
Save each updated request.

Each retained request URL should now reference {{base_url}} instead of repeating the stable value.

A cinema value earns its own variable only when two or more verified request uses establish the same reusable structure.

Confirm whether the same non-sensitive cinema value appears in two or more verified request uses.

✔️ Two or more uses establish it

Select Add variable in the collection Variables tab.
Enter cinema_value as the variable name.

You should see a new collection-variable row named cinema_value.

Enter the verified non-sensitive cinema value as its local value.
Replace the repeated cinema value in the matching requests with {{cinema_value}}.

The matching request URLs should now reference {{cinema_value}}.

Keep the cinema_value value unshared with the Postman cloud.

ⓧ Fewer than two uses establish it

One occurrence does not establish a reusable request structure. Keep that non-sensitive value directly in the verified request.

Leave cinema_value absent from the collection.

Variable reference looks wrong?

Check that the names are exactly base_url or cinema_value. Confirm that each request uses matching double-brace references.

Ask for help with the local variable setup: help me troubleshoot my Postman collection variables.

Before you inspect the final collection, how many requests do you expect to remain after every exclusion?

Select the 01 Read-Only Replay folder.
Confirm that every retained request uses GET.
Confirm that every retained request name matches a documented cinema or menu browser action.
Confirm that every retained request contains no private, session, cart, or payment value.
Confirm that every retained request references {{base_url}}.
Review the Overview for every Session-dependent: observe only exclusion.

You should see only individually sent sanitized GET requests in 01 Read-Only Replay. Each request should support a documented browser action.

If no behind-the-scenes request survived, the folder should contain only the public page baseline. The Overview should retain all excluded traffic as redacted metadata.

Your collection variables should remain local. No Collection Runner, monitor, payment entry, or order submission was used.

That is the hard part complete. Your collection now demonstrates public read-only traffic without preserving or replaying the ordering session.

Secret mission

Compare a Second Cinema Capture

Capture menu traffic for a second HOYTS cinema without adding another item. Compare both captures to separate stable request structure from cinema-specific or session-dependent values.

Clean Up Your Resources

Your finished artifact uses Postman's Free plan, so the project remains at $0. Choose whether to retain the sanitized learning artifact, pause your work, or remove it.

Resources you used:

The Postman collection HOYTS Food Ordering Flow - Read Only with its 01 Read-Only Replay folder.
Local collection variables for base_url plus any proven cinema_value value.
The redacted flow map plus the second-cinema comparison in the collection Overview.
Temporary Browser Tool Network and Interactions records.
Any remaining cart item from the normal HOYTS journey.

Keep everything running

Keeping everything preserves your sanitized collection for future manual learning sessions. There are no ongoing project costs.

Retain the HOYTS Food Ordering Flow - Read Only collection in your writable workspace.
Keep base_url plus any proven cinema_value value local to the collection.
Continue sending retained read-only requests manually one at a time.
Leave Collection Runner, monitors, plus schedules unused for this collection.

Pause - I'll come back to this later

Pausing closes the active browsing session while preserving your sanitized collection. You can return to the documented flow without capturing another order.

Close the Browser Tool tab from earlier.
Leave the HOYTS Food Ordering Flow - Read Only collection saved in Postman.
Keep the collection-variable values local.
Leave Collection Runner unused.
Leave monitors unscheduled for this collection.

Delete - I don't want to use this again

Deleting the collection is permanent. This option also clears the temporary capture records plus any remaining cart state.

Return to the normal HOYTS interface in the Browser Tool from earlier.
Remove any remaining cart items through the visible cart controls.
Sign out through the current account menu if you signed in.
Select the Network tab.
Click Clear to remove its request records.
Select the Interactions tab.
Use the tab's clear control to remove its interaction records.

The Network and Interactions lists are now empty.

Return to the Collections sidebar in Postman.
Open the action menu beside HOYTS Food Ordering Flow - Read Only.
Choose the option that deletes the collection.
Confirm the deletion in the dialog.

You no longer see the collection under Collections. Its local variables, redacted flow map, second-cinema comparison, plus read-only replay folder are removed with it.

Nice Work!

You did it! You traced a normal HOYTS food-ordering journey with the Postman Browser Tool to produce a sanitized read-only Postman collection.

You've learned how to:

Build a redacted flow map that connects each browser interaction to captured request evidence plus a safety classification.
Apply a safe replay boundary that keeps only sanitized public GET requests executable while cart, checkout, payment, order-submission, uncertain, plus session-dependent traffic stays documentation-only.
Build a reusable read-only collection with local collection variables for proven stable non-sensitive values.
Secret Mission: Complete a second-cinema comparison that separates Stable, Cinema-specific, plus Session-dependent components across corresponding menu-related GET traffic.

Ready to quiz yourself?