Most getting-started guides are thinly disguised feature lists. This walkthrough covers what actually matters when generating synthetic identities on Another.IO, including the parts that take most users weeks to stumble into.
No Signup. No Setup. No Patience Required.
No account creation. No credit card. No email verification loop that makes you question whether the product wants customers or hostages.
You land on the Another.IO homepage, click "Generate Identity," and get a complete synthetic persona in under two seconds. Name, date of birth, country-specific address, phone number, employer, financial data. All cross-referenced, all algorithmically generated, none of it connected to a real person.
Compare that to the usual alternatives. Faker libraries require a dev environment. Enterprise synthetic data platforms want a sales conversation before showing you the dashboard. The free generators scattered across the internet tend to produce disconnected data points: a Japanese name paired with an American phone number and a postcode from nowhere. Another.IO handles the coherence problem automatically, which turns out to be the feature that actually matters.
That speed matters when you're in the middle of a testing sprint. Generating forty identities in an afternoon is a realistic workload for a QA team working through signup flow variations, and spending three minutes configuring each one is not an option. The one-click model treats identity generation as a utility. Pull the lever, get the output, use it.
What the Identity Page Shows You
Every generated identity gets its own page, organised into tabs. The layout is deliberately simple, but the depth underneath surprises most new users.
The Overview Tab
Name, age, gender, country, unique ID. Standard profile card. That unique ID becomes relevant later for API calls and bookmarking, though most people ignore it entirely until they've generated their twentieth identity and lost track of which one they used for which project.
The overview also shows creation timestamp and current status: public or bookmarked. Useful for managing identities across testing scenarios. Less useful if you just need a quick throwaway profile to fill out a form.
The Profile Tab
Below the headline data sits the full profile: employer, job title, physical characteristics, financial details. Card numbers that pass Luhn validation but aren't connected to real accounts. National identification numbers formatted correctly for the selected country. Enough data to populate any registration form, KYC workflow, or user profile you're likely to encounter in the wild.
The financial data deserves a specific mention. Generated card numbers pass client-side format validation and satisfy Luhn checks. They won't process an actual transaction, which is the point. If your staging environment uses Stripe test mode or a similar sandbox, having realistic card numbers in the database makes debugging considerably more pleasant than seeing rows of "4242424242424242" across every test record.
The Email Inbox Is the Actual Killer Feature
This catches people off guard. Every generated identity comes with a functional email address. Not a placeholder. Not a simulated inbox. A working address that receives messages in real time.
Send a verification email from whatever service you're testing. It shows up in the inbox. HTML renders correctly. Attachments come through. Headers are visible for inspection. No polling delay. No "check back in five minutes." Messages arrive as they would in any mail client, minus about 200 megabytes of Electron packaging.
QA engineers use this to test signup flows, welcome sequences, password resets, and two-factor code delivery. Security researchers use it to probe phishing kits without burning real inboxes. Privacy-conscious users hand it to services they don't trust. Developers testing email-triggered workflows avoid the workaround of maintaining a bank of Gmail accounts that Google periodically locks for "suspicious activity."
If you've used disposable email services before, the difference shows up fast. Mailinator addresses are blocked by half the services on the internet. Guerrilla Mail expires in an hour. Most throwaway services sit on public blocklists that any halfway-competent signup form checks against. The addresses from Another.IO are unique per identity and not on the standard blocklists, which means they actually work for the flows you're trying to test. Surprisingly rare quality in disposable email.
The inbox is receive-only. You can read incoming messages but can't compose and send from the address. For the overwhelming majority of testing scenarios that's irrelevant: verification flows, notification testing, and inbox placement checks are all receive-side operations. But knowing the limitation upfront beats discovering it halfway through building a two-way email testing workflow.
One thing that's genuinely well executed: the inbox persists for bookmarked identities. Set up an identity, point your staging environment's notification system at it, and come back weeks later to find every email sitting there, searchable and rendered. That quiet reliability is unusual for a free tool.
Country-Specific Data Coherence
Generating random data is trivial. Any script can concatenate a first name, a surname, and a string of digits. What separates useful synthetic data from noise is internal coherence: does the identity hold together as a plausible person from a specific place?
Select France. The identity arrives with a mobile number starting with 06 or 07, a five-digit postal code, an address formatted the French way, and an employer that isn't wildly implausible for the region. Select Germany. Phone numbers follow the +49 format, addresses conform to German postal conventions, and the national insurance number matches the expected pattern.
Anyone who's tried seeding a staging database with hand-crafted fake data knows the failure cascade that follows incoherent profiles. A German phone number next to an American zip code next to an Australian employer name. Client-side validation catches some of it. Downstream services flag more. And the worst bugs slip through as intermittent failures that nobody can reproduce because they depend on a specific data inconsistency that only exists in the test environment.
The coherence matters most for localisation testing. Sending a checkout form a German postcode paired with an American state abbreviation doesn't test anything useful. It tests your validation error messages, at best. Coherent synthetic identities let you test the actual happy path for each locale, which is where the subtle bugs hide: the postcode field that's the wrong length, the phone number input that silently strips the country code, the address form that assumes everyone has a zip code.
Current country coverage spans most of Western Europe, North America, Australia, and parts of Asia-Pacific. The depth varies by region. UK identities include National Insurance numbers and properly formatted postcodes. Less common regions might have thinner profile data. Worth checking what fields your test actually requires before building fixtures around a specific country.
Bookmarking and Persistence
Unbookmarked identities stay accessible via their direct URL, but the persistence window is deliberately vague. The system manages storage dynamically, and "for a while" is the most honest answer available. Treat unbookmarked identities as ephemeral. Fine for a single testing session. Not something to build a two-week QA cycle around.
Bookmarked identities persist indefinitely. No expiration timer. The inbox keeps receiving emails. Bookmark the identity the moment you create it if there's any chance you'll want it again. Trying to relocate an unbookmarked identity three days later by scrolling through browser history is exactly as miserable as it sounds.
Managing Multiple Identities
Once you move past single-identity testing, organisation becomes the real challenge. The platform doesn't have a built-in project management layer, so keeping track of which identities belong to which test scenarios falls on you. Bookmark identities you need, un-bookmark completed projects, keep the list clean.
For teams, the simplest approach is often a shared document mapping identity IDs to test cases. Nothing elaborate: a spreadsheet row, a page in the project wiki, a comment in the CI configuration. The identities are accessible to anyone with the URL, so sharing across team members doesn't require account coordination.
The API
Everything on the web interface is available through the REST API. Generate identities programmatically, specify country and gender parameters, retrieve profile data as JSON. Standard conventions, bearer token authentication, JSON responses. The documentation covers the endpoint specifics.
Where the API earns its keep is in automated testing pipelines. Instead of maintaining a static fixture file of test users that grows stale, creates hard-coded dependencies, and eventually breaks when someone updates the schema, you generate fresh identities per test run. Each run gets unique, internally coherent data. If a test fails, the identity's unique ID makes it traceable without digging through application logs.
One pattern that works well in practice: generate a fresh identity at the start of each CI run and pass the profile data into the test suite as environment variables. The unique ID goes into the test report metadata. When something fails in the pipeline, tracing back to the exact synthetic user that triggered the failure takes seconds rather than hours of log archaeology.
Rate limits are generous enough for normal testing workloads. Not designed for industrial-scale bulk generation. If you need ten thousand identities for a load test, batch the requests and add a small delay between calls. Hammering the endpoint without pacing gets you throttled, which is fair enough.
The Mistakes Everyone Makes
Three things trip up new users consistently enough to be worth flagging.
The email addresses are functional, but the inboxes are public. Anyone with the address can view incoming messages. That's fine for testing verification flows and notification delivery. Not fine for creating accounts on services where incoming email contains anything sensitive. Keep the boundary clear: synthetic identities are for testing and privacy workflows, not for building a second digital life you'd rather keep private.
Generated financial data passes format validation, not transaction processing. Card numbers look correct in a database and satisfy Luhn checks, but they won't authorise a real charge. Use your payment processor's test mode alongside the synthetic data when testing checkout flows end-to-end.
Not all countries have the same data depth. A UK identity gives you deep, well-structured profile data across every expected field. An identity for a newer or less common region might return fewer fields or less granular formatting. Check what your test scenario actually needs before building fixtures around a specific country's data set.
One smaller note: the email domain format means some services may reject the address, the same way they reject other known disposable domains. If a signup form blocks it, that's the service's domain blocklist at work, not a problem with the email system. It does tell you something useful about how aggressively that service validates new registrations.
After the First Identity
The getting-started workflow takes about five minutes. Generate an identity. Explore the tabs. Send a test email to the address and watch it arrive. Bookmark the identity if you want to keep it. That's the core loop.
From there, the platform extends into document generation, VPN integration, and SMS verification. Each module builds on the same identity system. But none of that is relevant until the base workflow clicks, and the base workflow is intentionally straightforward.
Start with one identity. Get comfortable with how the email works. Then expand as your testing or privacy requirements demand it. The learning curve is about five minutes. The time savings compound from there, especially if the current approach involves hand-maintained test fixtures or a shared pool of Gmail accounts across the development team. Neither of those scales, and both introduce problems that purpose-built synthetic identities solve cleanly.