Skip to main content

ACCELQ Integration

MailSlurp fits ACCELQ best when ACCELQ drives the browser or API steps and MailSlurp handles inbox state over HTTP. A common pattern is to create a fresh inbox, use that address in the app under test, wait for the verification email, extract the OTP, and feed it back into the ACCELQ flow.

Typical ACCELQ workflow​

  1. Start a new ACCELQ test or reusable action.
  2. Call createInboxWithDefaults in a REST or API step and store the returned id and emailAddress.
  3. Use emailAddress in the sign-up or password reset UI flow.
  4. Trigger the app action that sends the OTP or verification email.
  5. Call waitForLatestEmail with the new inbox ID.
  6. Call getEmailContentMatch to extract the verification code.
  7. Use the extracted code in the next ACCELQ step and assert success.

Authenticate requests​

Use your MailSlurp dashboard API key in each MailSlurp request:

  • Recommended: x-api-key: YOUR_API_KEY
  • Alternative: ?apiKey=YOUR_API_KEY

In low-code runners, header-based authentication is usually easier to store in environment variables, shared request definitions, and reusable actions.

Create an inbox for the test run​

Operation createInboxWithDefaults not found.

Use the returned emailAddress in the ACCELQ step that fills your app's registration or login form.

Wait for the verification email​

Operation waitForLatestEmail not found.

This step lets ACCELQ block on the real email instead of using a fixed delay in the test flow.

Extract the OTP or confirmation code​

Operation getEmailContentMatch not found.

Use a capture group in the regex pattern so the code is returned in matches[1], then map that value into the ACCELQ step that completes verification.

Visual fallback for low-code debugging​

If you prefer a visible inbox while building the flow, use the MailSlurp test interface. It is useful during recorder-style test authoring, exploratory QA, and debugging email content before you move the final checks into direct API calls.