Debugging ToolsLocal Requests

Local Requests

Local Requests (also called Ad-hoc Requests) are quick, private API tests stored only in your browser. Perfect for temporary debugging and exploratory testing without cloud storage.

See also: Debugging Tools Overview for comparing Local Requests with Debug Collections and Test Flows.

What Are Local Requests?

Local Requests are stored in your browser’s localStorage and never uploaded to ReAPI’s servers. They’re designed for:

  • Quick testing: Instant creation, no setup required
  • Complete privacy: Never leaves your browser
  • Temporary debugging: For one-off tests you don’t need to keep
  • Sensitive endpoints: Test without saving to cloud
  • Fast iteration: No sync delays

Key Characteristics

Advantages:

  • 100% Private: Never uploaded to servers
  • Instant: No save/sync overhead
  • Simple: Flat list, no organization needed
  • Offline: Works without network connection

Limitations:

  • Single device: Only accessible on current browser
  • No backup: Lost if you clear browser data
  • No organization: Simple flat list only
  • No sharing: Cannot collaborate with team

Creating a Local Request

Step 1: Access Local Requests

  1. Open ReAPI Studio
  2. Click the Tools tab (wrench icon)
  3. Select Local Requests tab
  4. Click Ad-hoc Request button

Step 2: Configure Request

A new request is created with defaults:

  • Method: GET
  • URL: /
  • Name: Empty (shows URL)

Configure your request:

Basic Settings:

Method: POST
URL: https://api.example.com/users
Title: Create User Test

Headers:

Content-Type: application/json
Authorization: Bearer your-token-here

Body:

{
  "email": "test@example.com",
  "name": "Test User"
}

Step 3: Send Request

  1. Click Send button
  2. Response appears in the bottom panel
  3. Request automatically saves to localStorage

Step 4: Iterate

  • Modify parameters
  • Try different values
  • Send multiple times
  • Inspect responses

Using Variables

Local Requests can reference Variable Groups:

# URL with variables
{{baseUrl}}/users/{{userId}}
 
# Headers
Authorization: Bearer {{authToken}}
 
# Body
{
  "apiKey": "{{apiKey}}",
  "environment": "{{env}}"
}

Linking Variable Groups

  1. Click Environment tab in request editor
  2. Select Variable Group
  3. Choose from available groups
  4. Variables are now available

Request Configuration

HTTP Methods

Supported methods:

  • GET
  • POST
  • PUT
  • DELETE
  • PATCH
  • HEAD
  • OPTIONS

Headers

Add common headers:

Authentication:

Authorization: Bearer {{token}}
X-API-Key: { { apiKey } }

Content Type:

Content-Type: application/json
Accept: application/json

Custom Headers:

X-Request-ID: { { $guid } }
X-Timestamp: { { $timestamp } }

Request Body

Supported body types:

JSON:

{
  "key": "value",
  "nested": {
    "field": "data"
  }
}

Form Data (URL-encoded):

key1=value1&key2=value2

Form Data (multipart):

  • Add form fields
  • Upload files (if needed)

Plain Text:

Raw text content

Managing Local Requests

Viewing Requests

All local requests appear in the left sidebar:

  • Shows HTTP method badge
  • Shows request title (if set)
  • Shows URL (if no title)
  • Click to open

Editing Requests

  1. Click request in sidebar
  2. Modify any settings
  3. Changes auto-save to localStorage

Renaming Requests

  1. Open request
  2. Click title field at top
  3. Enter descriptive name
  4. Press Enter

Good naming:

  • “Test Login API”
  • “Create User with Admin Role”
  • “Fetch User 123”

Bad naming:

  • “Request 1”
  • “Test”
  • Empty

Deleting Requests

  1. Open request
  2. Click trash icon (🗑️) in toolbar
  3. Confirm deletion

Note: Deletion is permanent (no undo).

Best Practices

When to Use Local Requests

✅ Good use cases:

  • Testing a new API endpoint during development
  • Quick debugging of a production issue
  • Experimenting with parameters
  • Testing with sensitive data you don’t want saved
  • One-off API calls

❌ Not ideal for:

  • Requests you’ll need tomorrow
  • Sharing with team members
  • Building a request library
  • Cross-device access
  • Long-term storage

Naming Convention

Use descriptive names:

✅ "Login - Admin User"
✅ "GET /users/123"
✅ "Test Payment Flow - Step 1"

❌ "Request"
❌ "Test 1"
❌ "/" (just the path)

Converting to Debug Collections

If a local request becomes useful:

  1. Copy the request configuration
  2. Go to Collections tab
  3. Create new request in a collection
  4. Paste configuration
  5. Delete local request if no longer needed

Browser Data Warning

Local requests are stored in localStorage:

  • Clearing browser data = losing all requests
  • Different browser = can’t access requests
  • Incognito mode = requests lost when closed

Recommendation: Don’t rely on local requests for important long-term work.

Troubleshooting

Request Not Saving

Symptom: Changes don’t persist

Solutions:

  • Check browser localStorage isn’t disabled
  • Check you’re not in private/incognito mode
  • Verify you have storage space
  • Try refreshing the page

Can’t Find Old Request

Symptom: Request disappeared

Possible causes:

  • Browser data was cleared
  • Using different browser/device
  • LocalStorage was reset
  • Using different ReAPI project (requests are per-project)

Prevention: Convert important requests to Debug Collections

Variables Not Resolving

Symptom: {{variable}} shown as-is in request

Solutions:

  • Check Variable Group is selected
  • Verify variable exists in selected group
  • Check variable name spelling (case-sensitive)
  • Ensure Variable Group is linked to request

Request Won’t Send

Check:

  • URL is valid
  • Network connection is active
  • Server is reachable
  • CORS settings (if localhost)
  • Authentication headers are correct

Comparison with Other Tools

Local Requests vs Debug Collections

AspectLocal RequestsDebug Collections
StorageBrowser onlyCloud server
AccessSingle browserAny device
SharingNoYes, with team
OrganizationFlat listFolders
BackupNoAutomatic
Use caseTemporaryLong-term

Migration path: Start with Local Request → Move to Debug Collection if useful

Local Requests vs Test Flows

AspectLocal RequestsTest Flows
ComplexitySingle requestMulti-step
Flow controlNoYes (IF/Loop)
Data extractionManualAutomatic
Use caseQuick testComplex scenario

When to upgrade: If you need multiple steps, use Test Flows instead

Privacy & Security

What Stays Local

  • Request configuration
  • Headers and body
  • Responses (optional)
  • Execution history

What Doesn’t Sync

  • Local requests never upload to cloud
  • Not visible to team members
  • Not backed up to servers
  • Not accessible on other devices

Security Considerations

Safe for:

  • Testing with production credentials (stays local)
  • Sensitive API keys
  • Personal access tokens
  • Private data

Remember:

  • Still transmitted over network to API
  • API server receives the data
  • Ensure API uses HTTPS
  • Responses stored in browser (clear if sensitive)

Tips & Tricks

Rapid Iteration

For quick testing:

  1. Keep request open
  2. Modify single parameter
  3. Press Send
  4. Check response
  5. Repeat

Using Templates

Create a “template” local request:

  1. Configure common settings
  2. Clone it for variations
  3. Modify specific fields
  4. Test different scenarios

Cleanup Strategy

Periodically delete old requests:

  • Delete after debugging issue
  • Remove experimental requests
  • Keep browser storage clean
  • Reduce clutter in sidebar

Keyboard Shortcuts

(Shortcuts depend on UI implementation)

Typical workflow:

  • Cmd/Ctrl + Enter: Send request
  • Cmd/Ctrl + S: Focus save/title
  • Cmd/Ctrl + K: Focus URL field

Next Steps


Questions? Join our Discord community for help!