ACCELQ Integration

ACCELQ integrates with MailSlurp by letting ACCELQ test flows call MailSlurp APIs for programmable inboxes, phone numbers, messages, and wait logic. ACCELQ can drive the application under test through Web, Mobile, API, Desktop, or Unified scenarios while MailSlurp handles the email and SMS side over the REST API.

The most reliable pattern is to create a fresh MailSlurp inbox during the ACCELQ run, use the generated emailAddress in the application flow, wait for the verification email, extract the OTP or link, and feed that value back into the next ACCELQ step.

MailSlurp concepts

Key MailSlurp API methods

These are the MailSlurp operations ACCELQ teams commonly start with. Each link opens the operation in the MailSlurp REST API reference.

ACCELQ products and where MailSlurp fits

ACCELQ uses related terms for product areas and APIs. In this guide, "API" can mean ACCELQ API testing, the MailSlurp REST API, or ACCELQ's external APIs for running and reporting on ACCELQ jobs. For MailSlurp email and SMS testing, use this map:

For most teams, the REST API path is the right default because it works across ACCELQ Web, API, Mobile, and Unified scenarios without adding runtime dependencies.

Choose an integration path

Recommended: REST Actions in ACCELQ

Create a small set of reusable ACCELQ Actions that call MailSlurp endpoints directly:

1. Create MailSlurp inbox
2. Wait for the matching MailSlurp email
3. Extract OTP from MailSlurp email
4. Delete the inbox created by the Scenario
5. Optional: Fetch the assigned test phone number and Wait for its SMS

This fits low-code ACCELQ projects because responses are JSON and ACCELQ can store extracted values as Action outputs or variables.

Faster API setup: import MailSlurp OpenAPI

MailSlurp publishes OpenAPI definitions that ACCELQ API projects can import to generate Actions for endpoints.

• OpenAPI JSON: https://api.mailslurp.com/v2/api-docs/
• Swagger/OpenAPI docs: https://swagger.mailslurp.com
• REST API reference: MailSlurp REST API

In ACCELQ, use the Swagger/OpenAPI import flow if it is available in your edition. Import only the MailSlurp endpoints your test team will maintain as reusable Actions. A focused import is easier to govern than publishing every MailSlurp endpoint into a shared module.

SDK and user extension option

MailSlurp has official SDKs for Java, C#, JavaScript, Python, and other languages, plus framework guides such as Selenium and Playwright.

Use SDKs when your ACCELQ run is orchestrated by a coded test harness, CI job, or helper service outside ACCELQ. Inside ACCELQ itself, prefer REST Actions unless you already use ACCELQ Java User Extensions and want to wrap MailSlurp SDK calls as custom commands.

Typical ACCELQ workflow

Use this sequence for sign-up, password reset, magic-link login, invitation, and email verification tests:

1. Start an ACCELQ Scenario or reusable Action.
2. Call createInboxWithDefaults and store the returned id and emailAddress.
3. Use emailAddress in the app under test.
4. Capture the current UTC timestamp, then submit the page or API request that causes your app to send the email.
5. Call waitForMatchingFirstEmail with the inbox id, start timestamp and expected subject.
6. Store the returned email id, subject, body, and any other values you need.
7. Call getEmailContentMatch with a regex pattern to extract an OTP, token, or link.
8. Use the extracted value in the next ACCELQ UI or API step.
9. Assert the application reaches the expected state for the generated email address.
10. Delete this run's inbox in teardown, including after failure. Retain redacted IDs and timings first if you need them for diagnosis.

Authenticate requests

Use your MailSlurp dashboard API key in each MailSlurp request:

• Header: x-api-key: YOUR_API_KEY

Keep the key out of request URLs, where it can appear in logs and copied links. Header-based authentication works with protected properties, shared request definitions, and reusable actions.

In ACCELQ, keep the key in an encrypted Global Property such as MAILSLURP_API_KEY, then reference it from REST request headers. If your ACCELQ REST configuration accepts header rows, set header name x-api-key and value from the property. If it accepts comma-separated headers, use the equivalent x-api-key={prop: MAILSLURP_API_KEY} form.

Also define MAILSLURP_BASE_URL as https://api.mailslurp.com so Actions can be reused across projects and updated centrally.

Create the core ACCELQ Actions

1. Create an inbox for the test run

Create a REST POST Action for this endpoint:

POST https://api.mailslurp.com/inboxes/withDefaults
x-api-key: YOUR_API_KEY
Accept: application/json

In ACCELQ, store these response values:

• id as mailSlurpInboxId
• emailAddress as mailSlurpEmailAddress

Verify the HTTP response succeeded before extracting values. In ACCELQ, use Get ReST Response for the body, then Get JSON Node value with $.id and $.emailAddress. Pass them as Action outputs for this Scenario execution, not mutable globals shared by parallel runs. Then use mailSlurpEmailAddress in the application step that registers, invites, or resets the user. See ACCELQ's REST response extraction guide.

POST /inboxes/withDefaults HTTP/1.1
Host: api.mailslurp.com
x-api-key: YOUR_API_KEY
Accept: */*

(
set -eu
response_file=$(mktemp)
trap 'rm -f "$response_file"' EXIT
status=$(curl --silent --show-error \
  --request POST \
  --url 'https://api.mailslurp.com/inboxes/withDefaults' \
  --header 'x-api-key: YOUR_API_KEY' \
  --header 'Accept: */*' \
  --output "$response_file" \
  --write-out '%{http_code}')
case "$status" in
  2??) mv "$response_file" 'response.bin' ;;
  *) printf 'HTTP %s\n' "$status" >&2; cat "$response_file" >&2; exit 1 ;;
esac
)

import { writeFile } from "node:fs/promises";

const response = await fetch("https://api.mailslurp.com/inboxes/withDefaults", {
  method: "POST",
  headers: {
    "x-api-key": "YOUR_API_KEY",
    "Accept": "*/*"
  },
  redirect: "manual",
  signal: AbortSignal.timeout(60000),
});
const responseBytes = Buffer.from(await response.arrayBuffer());
if (!response.ok) {
  throw new Error(`HTTP ${response.status}: ${responseBytes.toString("utf8")}`);
}
await writeFile("response.bin", responseBytes);

import http.client
from pathlib import Path
from urllib.parse import urlsplit

url = urlsplit("https://api.mailslurp.com/inboxes/withDefaults")
headers = {
    "x-api-key": "YOUR_API_KEY",
    "Accept": "*/*"
}
connection_class = http.client.HTTPSConnection if url.scheme == "https" else http.client.HTTPConnection
connection = connection_class(url.hostname, url.port, timeout=60)
try:
    path = (url.path or "/") + ("?" + url.query if url.query else "")
    connection.request("POST", path, headers=headers)
    response = connection.getresponse()
    response_bytes = response.read()
    if not 200 <= response.status < 300:
        raise RuntimeError(f"HTTP {response.status}: {response_bytes.decode('utf-8', errors='replace')}")
    Path("response.bin").write_bytes(response_bytes)
finally:
    connection.close()

2. Wait for the verification email

Create a REST POST Action that accepts mailSlurpInboxId, the expected subject and a UTC startedAt timestamp captured immediately before the application sends. URL-encode the timestamp when building the query string. The subject below is an example; use the subject your application actually sends.

POST https://api.mailslurp.com/waitForMatchingFirstEmail?inboxId=INBOX_ID&timeout=60000&since=URL_ENCODED_START_TIME&unreadOnly=false
x-api-key: YOUR_API_KEY
Content-Type: application/json
Accept: application/json

{"matches":[{"field":"SUBJECT","should":"EQUAL","value":"Verify your account"}]}

Give ACCELQ's HTTP call a timeout above 60 seconds and the complete Scenario enough time for all its steps. Validate the response status, then assert that to contains this run's address and subject equals the expected value. Store the returned email id only after those checks. A new inbox isolates parallel tests; the subject and time boundary distinguish this request from other messages within the same workflow.

Use unreadOnly=false so opening the message for debugging does not change the result. A missing message must fail the Action at its deadline. Do not fall back to the latest message in a shared inbox.

{
  "matches": [
    {
      "field": "SUBJECT",
      "should": "MATCH",
      "value": "value"
    }
  ],
  "conditions": [
    {
      "condition": "HAS_ATTACHMENTS",
      "value": "TRUE"
    }
  ],
  "ai": {
    "prompt": "value",
    "aiOptions": {
      "model": "BALANCED_V1",
      "maxTokens": 1,
      "maxCandidates": 1,
      "maxOutputTokens": 1,
      "minimumConfidence": 1
    }
  }
}

POST /waitForMatchingFirstEmail?inboxId=00000000-0000-4000-8000-000000000000 HTTP/1.1
Host: api.mailslurp.com
x-api-key: YOUR_API_KEY
Content-Type: application/json
Accept: */*

{}

(
set -eu
response_file=$(mktemp)
request_body=$(mktemp)
trap 'rm -f "$response_file" "$request_body"' EXIT
{
  printf '%b' '{}'
} > "$request_body"
status=$(curl --silent --show-error \
  --request POST \
  --url 'https://api.mailslurp.com/waitForMatchingFirstEmail?inboxId=00000000-0000-4000-8000-000000000000' \
  --header 'x-api-key: YOUR_API_KEY' \
  --header 'Content-Type: application/json' \
  --header 'Accept: */*' \
  --output "$response_file" \
  --write-out '%{http_code}' \
  --data-binary "@$request_body")
case "$status" in
  2??) mv "$response_file" 'response.bin' ;;
  *) printf 'HTTP %s\n' "$status" >&2; cat "$response_file" >&2; exit 1 ;;
esac
)

import { writeFile } from "node:fs/promises";

const body = Buffer.concat([
  Buffer.from("{}", "utf8")
]);

const response = await fetch("https://api.mailslurp.com/waitForMatchingFirstEmail?inboxId=00000000-0000-4000-8000-000000000000", {
  method: "POST",
  headers: {
    "x-api-key": "YOUR_API_KEY",
    "Content-Type": "application/json",
    "Accept": "*/*"
  },
  body,
  redirect: "manual",
  signal: AbortSignal.timeout(60000),
});
const responseBytes = Buffer.from(await response.arrayBuffer());
if (!response.ok) {
  throw new Error(`HTTP ${response.status}: ${responseBytes.toString("utf8")}`);
}
await writeFile("response.bin", responseBytes);

import http.client
from pathlib import Path
from urllib.parse import urlsplit

url = urlsplit("https://api.mailslurp.com/waitForMatchingFirstEmail?inboxId=00000000-0000-4000-8000-000000000000")
headers = {
    "x-api-key": "YOUR_API_KEY",
    "Content-Type": "application/json",
    "Accept": "*/*"
}
body = b"".join([
    "{}".encode("utf-8")
])
connection_class = http.client.HTTPSConnection if url.scheme == "https" else http.client.HTTPConnection
connection = connection_class(url.hostname, url.port, timeout=60)
try:
    path = (url.path or "/") + ("?" + url.query if url.query else "")
    connection.request("POST", path, body=body, headers=headers)
    response = connection.getresponse()
    response_bytes = response.read()
    if not 200 <= response.status < 300:
        raise RuntimeError(f"HTTP {response.status}: {response_bytes.decode('utf-8', errors='replace')}")
    Path("response.bin").write_bytes(response_bytes)
finally:
    connection.close()

3. Extract the OTP, token, or link

Create a REST POST Action that accepts emailId and pattern inputs.

POST https://api.mailslurp.com/emails/EMAIL_ID/contentMatch
x-api-key: YOUR_API_KEY
Content-Type: application/json
Accept: application/json

{
  "pattern": "(?i)(?:verification code|OTP|code)[:\\s-]*([0-9]{6})(?![0-9])"
}

This pattern is for a six-digit code next to the words "verification code", "OTP" or "code". Adapt it to your template's actual wording. getEmailContentMatch uses Java-style regular expressions and returns the full match followed by capture groups. Verify the response contains matches[1] before reading it, then validate that its entire value is six ASCII digits. Keep it as a string so 012345 does not become 12345.

The first regex match is not proof that an email contains only one candidate. If your template can contain multiple codes, use getEmailCodes with a template-specific pattern and inspect the returned candidates; fail rather than selecting arbitrarily when more than one plausible code remains. Keep the email ID for troubleshooting instead of logging the code itself.

{
  "pattern": "value"
}

POST /emails/00000000-0000-4000-8000-000000000000/contentMatch HTTP/1.1
Host: api.mailslurp.com
x-api-key: YOUR_API_KEY
Content-Type: application/json
Accept: */*

{
  "pattern": "value"
}

(
set -eu
response_file=$(mktemp)
request_body=$(mktemp)
trap 'rm -f "$response_file" "$request_body"' EXIT
{
  printf '%b' '{\0012  "pattern": "value"\0012}'
} > "$request_body"
status=$(curl --silent --show-error \
  --request POST \
  --url 'https://api.mailslurp.com/emails/00000000-0000-4000-8000-000000000000/contentMatch' \
  --header 'x-api-key: YOUR_API_KEY' \
  --header 'Content-Type: application/json' \
  --header 'Accept: */*' \
  --output "$response_file" \
  --write-out '%{http_code}' \
  --data-binary "@$request_body")
case "$status" in
  2??) mv "$response_file" 'response.bin' ;;
  *) printf 'HTTP %s\n' "$status" >&2; cat "$response_file" >&2; exit 1 ;;
esac
)

import { writeFile } from "node:fs/promises";

const body = Buffer.concat([
  Buffer.from("{\n  \"pattern\": \"value\"\n}", "utf8")
]);

const response = await fetch("https://api.mailslurp.com/emails/00000000-0000-4000-8000-000000000000/contentMatch", {
  method: "POST",
  headers: {
    "x-api-key": "YOUR_API_KEY",
    "Content-Type": "application/json",
    "Accept": "*/*"
  },
  body,
  redirect: "manual",
  signal: AbortSignal.timeout(60000),
});
const responseBytes = Buffer.from(await response.arrayBuffer());
if (!response.ok) {
  throw new Error(`HTTP ${response.status}: ${responseBytes.toString("utf8")}`);
}
await writeFile("response.bin", responseBytes);

import http.client
from pathlib import Path
from urllib.parse import urlsplit

url = urlsplit("https://api.mailslurp.com/emails/00000000-0000-4000-8000-000000000000/contentMatch")
headers = {
    "x-api-key": "YOUR_API_KEY",
    "Content-Type": "application/json",
    "Accept": "*/*"
}
body = b"".join([
    "{\n  \"pattern\": \"value\"\n}".encode("utf-8")
])
connection_class = http.client.HTTPSConnection if url.scheme == "https" else http.client.HTTPConnection
connection = connection_class(url.hostname, url.port, timeout=60)
try:
    path = (url.path or "/") + ("?" + url.query if url.query else "")
    connection.request("POST", path, body=body, headers=headers)
    response = connection.getresponse()
    response_bytes = response.read()
    if not 200 <= response.status < 300:
        raise RuntimeError(f"HTTP {response.status}: {response_bytes.decode('utf-8', errors='replace')}")
    Path("response.bin").write_bytes(response_bytes)
finally:
    connection.close()

4. Use the extracted value in ACCELQ

After the MailSlurp Actions run, the rest of the Scenario is standard ACCELQ automation:

1. Enter verificationCode in the app's OTP field, or call your app's verification API with it.
2. Submit the form or request.
3. Verify the expected account state and that the account belongs to mailSlurpEmailAddress. A generic success response is not enough to establish which user was verified.

For magic links, select the URL with your application's expected origin and verification path before navigating. Do not assume the first URL is the login link. Add separate cases for expired tokens, replay and resend invalidation according to the application's rules, each with its own test user.

For API-only ACCELQ tests, the same sequence works without browser steps: create inbox, call your application's sign-up API with the generated address, wait for the email, extract the code, then call your application's verify endpoint.

OpenAPI import checklist

If you use ACCELQ Automate API or ACCELQ Unified with Swagger/OpenAPI import:

1. Import https://api.mailslurp.com/v2/api-docs/ as the Swagger/OpenAPI source.
2. Select only the endpoints needed for your first workflow, such as inbox creation, wait methods, email content matching, and cleanup.
3. Set the base URL to https://api.mailslurp.com.
4. Add x-api-key authentication using an encrypted ACCELQ property.
5. Review generated Action names so non-developers can understand them.
6. Add response extraction for id, emailAddress, and matches[1].
7. Save the generated Actions into a shared Context or module that test authors can reuse.

OpenAPI import is a shortcut for building Actions. It does not replace test design: still wrap low-level API calls in clear business Actions such as Create disposable test email address or Get verification code for inbox.

Working with ACCELQ JSON responses

MailSlurp API responses are JSON. In ACCELQ, extract values from REST responses with JSONPath-style commands or response-node extraction:

• Inbox ID: $.id
• Email address: $.emailAddress
• Matched email ID: $.id
• Email subject: $.subject
• Regex capture: $.matches[1], after verifying it exists and has the expected format

Keep these values as Action outputs where possible. That makes your Scenario readable and avoids repeating JSON parsing logic in every test case.

Web, API, and Unified examples

Web sign-up with email OTP

1. ACCELQ Web opens the sign-up page.
2. MailSlurp REST Action creates an inbox.
3. ACCELQ Web enters the generated email address and submits the form.
4. MailSlurp REST Action waits for the expected subject after the recorded request time.
5. MailSlurp REST Action extracts the OTP.
6. ACCELQ Web enters the OTP and verifies the account is active.

API registration with magic link

1. MailSlurp REST Action creates an inbox.
2. ACCELQ API calls your app's registration endpoint with the generated address.
3. MailSlurp REST Action waits for the email.
4. ACCELQ extracts either the full link from the email body or a token parameter from the link.
5. ACCELQ API calls the verification endpoint and asserts the response.

Unified Web plus API regression

1. ACCELQ API creates a user with a MailSlurp email address.
2. ACCELQ Web signs in as that user.
3. The app sends a security notification.
4. MailSlurp waits for the notification and asserts subject, sender, and body content.
5. ACCELQ continues with UI assertions in the same Scenario.

SMS and phone verification

MailSlurp can also manage real phone numbers and inbound SMS. Use the same ACCELQ pattern:

1. Fetch a phone number assigned for the test. Allocate a new number only when the account's phone rental configuration and the test plan call for it.
2. Use the number in your app's phone verification flow.
3. Wait for the inbound SMS.
4. Extract the OTP from the SMS body.
5. Continue the ACCELQ verification step.

Start with email first; inbox setup has fewer moving parts. Add SMS after the reusable REST Action pattern is working.

Reliability practices

• Create a fresh inbox per test run for parallel ACCELQ jobs.
• Use unreadOnly=false with a run-specific inbox, expected subject and since boundary so read state does not affect the result.
• Use explicit timeouts such as 60000 or 120000 milliseconds, then fail the ACCELQ step if the email does not arrive.
• Match on subject, sender, or body when a shared inbox could receive more than one message.
• Store API keys in encrypted ACCELQ properties, not hardcoded request definitions.
• Keep regex patterns specific enough to avoid capturing unrelated numbers.
• Delete the inbox owned by this run in teardown; configure expiry as a fallback for interrupted runners. Never clean up by deleting all account inboxes.
• Prefer direct API waits over fixed delays or visual inbox polling in CI.

When to use the MailSlurp test interface

The MailSlurp test interface is useful when building or debugging a new ACCELQ flow:

1. Open https://test.mailslurp.com.
2. Sign in with a MailSlurp API key.
3. Create an inbox and copy its email address.
4. Use that address in the ACCELQ-recorded app flow.
5. Inspect the received email visually before turning the same steps into REST Actions.

Use the visual interface for authoring and debugging, not as the primary CI path. REST Actions are faster, easier to parameterize, and more deterministic.

Terminology notes

• MailSlurp REST API: the API ACCELQ calls to create inboxes, wait for email, extract OTPs, send email, manage phone numbers, and inspect messages.
• MailSlurp OpenAPI definition: the machine-readable schema ACCELQ can import to generate REST Actions.
• MailSlurp SDKs: language clients for coded test suites or helper services. Use them with Java user extensions or external runners when REST Actions are not enough.
• ACCELQ API testing: ACCELQ's product area for testing APIs, which can call MailSlurp like any other REST service.
• ACCELQ external APIs: APIs for controlling ACCELQ itself from CI or external tools. These are not required for MailSlurp email and SMS verification inside ACCELQ Scenarios.

Troubleshooting

• 401 or 403: confirm the x-api-key header is present and the ACCELQ property resolves at runtime.
• Timeout waiting for email: confirm the app sent to emailAddress, inspect its send event, and verify the subject/time filters. Distinguish the MailSlurp wait deadline from ACCELQ's HTTP timeout before increasing either.
• 429: inspect account limits and test concurrency; avoid tight retry loops. Keep retries within the test's total deadline.
• OTP extraction returns no value or the wrong value: validate the capture exists, tighten it to the template, and reject ambiguous candidates. Preserve leading zeros.
• OpenAPI import generates too many Actions: import a smaller endpoint set or delete unused generated Actions before publishing the shared module.
• Parallel runs read the wrong email: create a fresh inbox per run, or wait with stricter matching conditions.

ACCELQ references

These ACCELQ resources are useful when configuring the ACCELQ side of the integration:

• ACCELQ product overview
• ACCELQ Unified platform
• REST API test automation in ACCELQ
• Importing Swagger definitions in ACCELQ
• Extracting data from REST API responses in ACCELQ
• Working with JSON in ACCELQ
• ACCELQ user extensions

Related docs

• MailSlurp REST API
• SDK libraries
• Java SDK
• C# SDK
• JavaScript SDK
• Selenium email and SMS testing
• Testing overview
• Wait for methods
• Test interface