Yes. The core app is MIT-licensed and free forever. No account required, no feature limits that expire, no trial period. Pro/Team tiers exist for advanced features (mock servers, monitors, docs generation) but the API client itself — sending requests, collections, environments, scripting, testing, CLI — is completely free.

• Collections: Wherever you choose — they're YAML files in directories you pick
• App data: ~/.apiark/ (settings, history, logs, window state)
• Nothing is in the cloud. Ever. Unless you git push your collection yourself

Yes. ApiArk works 100% offline for core workflows. You only need internet to: send requests to remote APIs, OAuth flows, and check for updates. See Configuration & Settings for details.

No. Zero telemetry by default. Optional crash reports (off by default) send only: stack trace, OS version, app version. Never your API data.

Yes. Import them via File → Import. ApiArk auto-detects Postman Collection v2.0/v2.1 format and converts everything including scripts, environments, and auth. See Import & Export.

Cause: The API server is not running or not reachable.

Fix:

• Verify the server is running: curl http://localhost:3000/health
• Check the port number in your URL
• If using Docker, ensure the container is running and ports are mapped
• If behind a VPN, check your VPN connection

Cause: The server uses a self-signed or untrusted certificate.

Fix:

• For development: Disable SSL verification in Settings → Network → SSL → Verify SSL: Off
• For custom CA: Add your CA certificate in Settings → Network → SSL → Custom CA Bundle
• For client certificates: Configure in Settings → Certificates

Only disable SSL verification for local development. Never disable it for production APIs.

Cause: The server didn't respond within the timeout period.

Fix:

• Increase timeout: Settings → Network → Timeout (default: 30000ms)
• Check if the server is overloaded
• Check network connectivity
• Try the request with cURL to verify it's not an ApiArk issue

Cause: This was a bug in earlier versions where WebSocket handshake headers weren't properly generated.

Fix: Update to v0.2.9 or later. This issue has been fixed.

Cause: A previous connection wasn't properly cleaned up.

Fix: Update to v0.2.9 or later. Failed/disconnected connections are now properly removed. As a workaround in older versions, restart the app.

Cause: Invalid YAML syntax in a request file.

Fix:

• Check the file in a text editor for syntax errors
• Common issues: unescaped special characters in strings, incorrect indentation
• If the file has Git merge conflict markers (<<<<<<<), resolve them first
• Validate your YAML at yamlvalidator.com

Cause: Another program (text editor, Git, etc.) modified a file that's open in ApiArk.

Options:

• Reload: Accept the external changes
• Keep Mine: Keep your current edits (overwrites external changes on next save)
• Diff: See what changed externally

Cause: Rare — can happen after a crash or disk issue.

What happens: ApiArk automatically detects corruption on startup, backs up the corrupt database, and creates a fresh one. You'll see a toast notification.

Recovery: The corrupt database is saved at ~/.apiark/data.db.corrupt.{timestamp}. You can try to recover data using SQLite tools.

1. Try deleting the window state file: rm ~/.apiark/state.json
2. Try deleting settings: rm ~/.apiark/settings.json (you'll lose preferences)
3. Check logs at ~/.apiark/logs/apiark.log for error details
4. If the issue persists, open an issue with the log file

Cause: macOS Gatekeeper blocking unsigned apps.

Fix:

xattr -cr /Applications/ApiArk.app

Or: Right-click → Open → Click "Open" in the dialog.

Fix:

chmod +x ApiArk_*.AppImage
./ApiArk_*.AppImage

If you get a FUSE error:

./ApiArk_*.AppImage --appimage-extract-and-run

Cause: New/unsigned application.

Fix: Click "More info" → "Run anyway". Code signing is being set up.

• Close unused tabs
• Clear request history (Settings → Data → Clear History)
• Large response bodies (>10MB) are automatically streamed to temp files
• Check for memory leaks: if RAM grows over time, please report it

• Normal cold start: <2 seconds
• If loading large collections (5000+ requests): Initial load may take longer, but subsequent loads use cached indexes
• Check if antivirus is scanning the binary on every launch

• ApiArk adds <10ms overhead to requests
• If requests seem slow, it's likely the server or network
• Compare with cURL to verify
• Check proxy settings — misconfigured proxy can add latency

1. Search existing issues: github.com/berbicanes/apiark/issues
2. Check logs: ~/.apiark/logs/apiark.log
3. Open a new issue: Include your OS, ApiArk version, and steps to reproduce
4. Join Discord: discord.gg/apiark for real-time help