QMail Two-Client GET Test Calls
GETClickable GET calls for testing the QMail send and receive lifecycle with Client1 listening on port 8081 and Client2 listening on port 8082. Every link opens in a new window and has a copy button.
Last reviewed against rest_core/api_src: 2026-05-18.
SN 55076
@chariot.pyramid.byte
SN 55077
@chariot.harbor.byte
How To Use These Links
These links assume core.exe is already running for Client1 and Client2. Use the status and identity links first. For deterministic manual PING/PEEK testing, stop Client2's background beacon before sending a test mail.
Links containing REPLACE_WITH_FILE_GUID, REPLACE_WITH_TASK_ID, REPLACE_WITH_EMAIL_ID, or REPLACE_WITH_ATTACHMENT_ID must be edited after a previous call returns the real value.
Client Readiness
Use these first to confirm both local rest_core clients are running and using the expected Mail wallet identity.
Expected SN 55076, address @chariot.pyramid.byte.
Expected SN 55077, address @chariot.harbor.byte.
Receiver Beacon Control
Stop Client2 background beacon polling before deterministic manual PING/PEEK tests, then start it again when finished.
Prevents the background beacon from racing manual PING/PEEK checks.
Beacon PEEK and PING
PEEK returns quickly. PING long-polls until a Tell arrives or the timeout expires.
timeout is rest_core client-side wait time, capped by the API; it is not the RAIDA server-side long-poll cap.
Split Upload then Tell
This is the main troubleshooting flow: upload first, inspect task/receipt state, then tell the receiver beacon.
Returns task_id and file_guid. Poll the task and receipt before calling Tell.
Requires this Client1 file to exist: E:\Client1\Client_Data\Wallets\Mail\Outgoing\attachment1.pdf
Uses repeated attachment_file_path parameters for E:\Client1\Client_Data\Wallets\Mail\Outgoing\attachment1.pdf and E:\Client1\Client_Data\Wallets\Mail\Outgoing\attachment2.pdf.
Replace the placeholder with the file_guid returned by upload.
Open immediately after starting Tell to observe tell.status in_progress, then refresh to see partial or success.
Convenience Upload and Tell
Use this when the caller wants the API to run upload and Tell back-to-back as one async task.
One-shot test: stages upload and fires Tell. PEEK/PING on Client2 should show files[] entries with attachment file types 10 and 11.
Observe and Download
After upload/tell, use task status and receipts on Client1, then PEEK/download on Client2.
Replace guid with the returned file_guid.
Replace id with the returned task_id. The upload response also returns the canonical task URL.
sender_sn is fallback metadata from the PEEK/PING notification; it is mainly needed if the pending tell row has already been consumed.
Confirms the downloaded email is present in Client2 local DB.
Replace email_id with the value returned by download. Receiver storage uses the file_guid as the email_id.
Use the email_id returned by download, not the upload task_id.
Uses since=0, so it shows the full current queue; compare with the pre-download PEEK to confirm the queue changed.