Skip to content
Facteur
FRGet started

Migration

Migrate from MailSlurp

Volume included in the subscription rather than an invoice you discover at the end of the month, per-inbox quotas, and data that stays in France. Here is what switching changes in your tests, line by line.

  • The invoice is known in advance, packs valid for a year
  • Quotas and alerts per inbox
  • Data in France, billed in euros, DPA online
Start the migrationThe migration, step by step

Migrating from MailSlurp does not change the shape of your tests: both APIs wait for the message, and that is what they got right. There is simply one inbox less to create, and no code left to extract from the body.

What switching changes is the invoice: volume included in the subscription and packs valid for a year, known in advance, instead of usage billed after the fact.

What makes a team move

The invoice stops being a surprise

Their subscription pays for features; messages are billed on top. While the volume is low it is the fairer model; the day the suite runs on every commit, nobody knows what the month will cost.

One inbox can no longer drain the budget

A ceiling per inbox and an alert threshold: a runaway test stops on its own quota instead of eating the whole organisation’s capacity.

Nothing to create before sending

Every inbox owns its subdomain, and any address ending in it is accepted from the first message. No inbox to create at the start of a test, none to delete at the end.

The message arrives in pieces

Body, headers, links and one-time code are extracted on reception. What your tests wrote as regular expressions is already done.

Translating your tests

Both APIs wait for the message rather than leaving your suite to wait for it: that is what MailSlurp got right, and we did not try to do it differently. What changes comes down to two things: there is no inbox to create, and no code left to extract.

createInbox() + waitForLatestEmail() → messages.waitFor()

login.spec.tsMailSlurp
const mailslurp = new MailSlurp({ apiKey: API_KEY });

// One inbox per test, to create and then to clean up.
const inbox = await mailslurp.createInbox();
await signUp(inbox.emailAddress);

const email = await mailslurp.waitForLatestEmail(
  inbox.id, 30_000,
);

const code = email.body.match(/\b\d{6}\b/)?.[0];
login.spec.tsFacteur
import { Facteur } from '@facteur-eu/sdk';

const facteur = new Facteur({ apiKey: process.env.FACTEUR_API_KEY });

// The address already exists: nothing to create, nothing to clean up.
const address = `signup-${Date.now()}@${inbox.domain}`;
await signUp(address);

const message = await facteur.messages.waitFor({
  inbox: inbox.id, sentTo: address, wait: 30_000,
});

const code = message.otp;

The MailSlurp code above follows their own published example; the sources are at the foot of this page. Ours runs as written.

The migration, step by step

The API correspondence is one line per call, and the migration goes file by file, both services running side by side until the suite is green.

  1. 1

    Create an account and an inbox

    The address already exists: every inbox owns its subdomain and accepts any address ending in it. The createInbox() at the top of each test goes, and the cleanup at the end goes with it.

  2. 2

    Replace the client

    The wait keeps its shape: waitForLatestEmail(inboxId, timeout) becomes messages.waitFor({ inbox, sentTo, wait }): the same blocking call, the same timeouts, one more parameter to target the address.

  3. 3

    Remove the extraction

    The one-time code arrives in message.otp, with the body, headers and links already parsed: the regular expression that dug through the body has nothing left to do.

  4. 4

    Run the suite, then cancel

    Nothing is transferred: test messages regenerate on the next run. Keep both accounts until everything is green.

The switch, at a glance

FacteurMailSlurp
Billing modelVolume included, then stacking packsSubscription + usage as you go
Predictable invoiceKnown in advanceVaries with the month’s usage
Volume included in the subscriptionYes, by planNo, billed separately
Per-inbox quotasYes, with overage alertsNot documented
SAML SSOIncluded from the Team planOn higher tiers
HostingFrance, billed in eurosOutside France, billed in dollars
DPADownloadable onlineOn request

Where this page’s claims come from

app.mailslurp.com/pricing/

Frequently asked

How much work is the migration from MailSlurp?

The correspondence is one line per call: createInbox() goes, waitForLatestEmail() becomes messages.waitFor(), and extracting the code becomes reading a field. The migration goes file by file, both services running side by side, and there is nothing to transfer: test messages regenerate.

Is Facteur more cost-effective than MailSlurp?

Yes, as soon as your test suites run regularly in CI. Because MailSlurp bills messages on top of the subscription, monthly invoices fluctuate unexpectedly. Facteur includes generous volume directly in plans, provides 1-year stacking capacity packs, and offers unlimited inboxes from the Team plan.

What is the difference between capacity packs and pay-as-you-go?

A Facteur capacity pack is bought up front, valid for 12 months, stacks with others, and is never lost on a downgrade. Pay-as-you-go computed afterwards fluctuates every month. The first model guarantees complete budget predictability for your team.

Why does migrating from MailSlurp simplify your test suite?

MailSlurp requires calling createInbox() at the start of every test and cleaning it up after. With Facteur, each inbox owns a subdomain accepting any address on the fly. You eliminate setup/teardown boilerplate, lower execution latency, and the one-time code arrives already extracted, in the API response, with no package to install.

Other comparisons: Mailisk · Mailtrap · Mailpit · Mailosaur

Your first inbox in two minutes

The free plan asks for no card. If you are switching tools, the steps fit on one page and can be tried on a single test.

Create a free accountHow to migrate