From first request to useful fixtures.

MAC and IMEI test data; hex and text conversion

POST /api/mac and POST /api/imei accept a JSON body and return {records, meta}. Both use existing authentication, generator availability, request limits and shared record allowances. Guests and Free accounts can request one record, Pro up to 50 and Developer up to 100. Bearer API access requires Developer. amount defaults to 1; format is json (default) or csv, with paid export access required for CSV.

MAC options: notation is colon (default), hyphen, dot or plain; uppercase is true by default; addressType is unicast (default) or multicast; administration is local (default) or universal. Output records contain mac. Universal-bit samples do not use a verified OUI database.

IMEI options: prefix is empty (random synthetic TAC-shaped prefix) or exactly eight digits. Output records contain imei as a 15-character string, including a calculated Luhn check digit. No TAC registry, device model or status lookup is performed. Both generators remove duplicates within each batch; results can overlap real identifiers or other batches.

MAC and IMEI inspectors and the Hex to Text Converter run locally in the browser, without record allowance or a separate API. Hex conversion supports strict ASCII and UTF-8, preserves control characters and rejects malformed byte sequences.

POST /api/imei
Content-Type: application/json
Authorization: Bearer YOUR_DEVELOPER_KEY

{"amount": 10, "prefix": "49015420"}

Usernames, random selections and custom datasets

POST /api/username, /api/random and /api/dataset accept JSON request bodies and return {records, meta}. Each generated row counts toward your shared allowance. Website guests and Free accounts can request one row; Pro allows 50 and Developer allows 100 per request. Bearer API access requires Developer. Set format to json (default) or csv; CSV requires paid access. These endpoints support POST only.

Username options: style is professional, gaming or short; keyword is optional (up to 20 A–Z letters); maxLength is 8–32 (default 20); separator is an empty string, underscore or period; numbers is a boolean (default true). Names are distinct within a batch, but platform availability is not checked. Some restrictive combinations cannot produce a full batch.

Random options: mode is numbers (default), pick, shuffle or teams; min/max are inclusive and between -1 billion and 1 billion; decimals is 0–4; unique defaults to true. List modes accept items (up to 100 strings, 200 characters each). pick uses amount; shuffle and teams output the entire list, so the number of entries must fit your batch allowance. With unique enabled, duplicate entries are removed. teams is 2–20 and must not exceed the remaining entries.

Dataset options: country selects one of the supported profile locales. columns contains 1–20 objects with unique names (1–40 characters, starting with a letter, then letters, numbers or underscores). Supported types are firstName, lastName, fullName, email, country, uuid, integer, decimal, date, choice, boolean, street, houseNumber, city, region, postalCode, addressQuality, iban, bankName, bic, ibanCountry, bankWarning, scenario, expectedValid and expectedError. Numeric columns accept min/max and decimal columns accept decimals (0–4). Date columns accept from/to as valid YYYY-MM-DD dates, inclusively in UTC. Choice columns require choices (1–50 nonempty strings of up to 100 characters).

Dataset names share one identity per row. Test email addresses use example.com. Address fields share one locality per row; streets and house numbers are synthetic. Banking fields share one IBAN source per row. bankCountry selects the IBAN country or territory independently of the name locale; optional bankCode requires paid access. Missing bank metadata stays null. Include bankWarning and addressQuality columns to retain coverage explanations. This is a flat builder without relational tables. An optional seed (up to 80 characters) makes results repeatable for the same settings and versions. Save column configurations in the website builder and reopen them from Dashboard → Presets. Generated rows are never saved.

The QR Code Generator is a browser-local website tool, without a generation API. It creates static URL, text, Wi-Fi and contact QR codes; no QR content is uploaded. Preview creation does not use record allowance. PNG/SVG downloads follow the Pro/Developer export rule and recheck access. Content is limited to 500 UTF-8 bytes, including formatting.

POST /api/dataset
Content-Type: application/json
Authorization: Bearer YOUR_DEVELOPER_KEY

{
  "country": "DE",
  "amount": 10,
  "columns": [
    { "name": "customer", "type": "fullName" },
    { "name": "email", "type": "email" },
    { "name": "total", "type": "decimal", "min": 10, "max": 500, "decimals": 2 },
    { "name": "status", "type": "choice", "choices": ["new", "paid"] }
  ]
}

Repeatable IBAN and dataset test cases

IBAN generation and datasets accept scenario: valid (default), invalid-checksum, wrong-length, invalid-characters, or mixed. Free users can generate individual scenarios; mixed requires Pro or Developer and ordinary batch limits apply. Published country examples require the valid scenario. Negative records explicitly describe their expected failure; additional checks may fail as a consequence. Metadata for an invalid IBAN refers to its original valid source and does not verify the altered value.

Pass seed to repeat a run. Responses include generatorVersion and dataVersion in meta.replay; seeded IBAN records also contain these fields. Supply both versions on later requests to reject silently changed engines or reference data. Saved seeded presets pin the versions automatically. Old versions are not retained; clear version fields to opt into current behavior. Seeded dataset JSON downloads use {records, meta} and include configuration and replay metadata; unseeded downloads retain their array shape. CSV contains selected columns, so retain configuration separately for replay.

POST /api/iban/validate also accepts cases: an array of {iban, expectedValid?, expectedError?}. It returns results containing actual validation and matchesExpectation (null when no expectation was supplied). An expected error is satisfied when that error code occurs, even if other checks also fail. Batch sizes follow the current plan; validation uses request limits but no record allowance. The ordinary single-IBAN and BIC requests remain supported.

The website provides Customer onboarding, Payment form testing and IBAN validation tests templates. Templates remain editable and use existing preset limits. The valid scenario is the default; the validation template selects mixed only for paid users. Validate results transfers the current IBANs through temporary session storage, clears it when read, and waits for an explicit validation click. Transfers expire after ten minutes.

Your first request

The API base path is /api on your application origin. The local preview runs at http://localhost:3000. Set GENORY_BASE_URL to the origin of your running instance and GENORY_API_KEY to a key created in Dashboard → API keys. The full key is shown only once.

Run this JavaScript example on your server. Never embed the key in a public frontend. Without code, choose a country and fields in the website generator, then generate and copy a record.

• 1. Activate the Developer plan in Dashboard → Subscription. Free and Pro do not include API access.
• 2. Open Dashboard → API keys, enter a name and select Create key. Copy the secret immediately; it is shown only once.
• 3. Store the key in a server environment variable and send it in the Authorization header. Use your deployed site origin as GENORY_BASE_URL, without /api.
• 4. Run the example below and read the records array. Check the HTTP status before processing the response.

const base = process.env.GENORY_BASE_URL;
const key = process.env.GENORY_API_KEY;
if (!base || !key) throw new Error("Configure base URL and API key");
const response = await fetch(new URL("/api/profile", base), {
  method: "POST",
  headers: {
    Authorization: "Bearer " + key,
    "Content-Type": "application/json"
  },
  body: JSON.stringify({
    country: "DE", amount: 1,
    fields: ["firstName", "lastName", "email", "iban"]
  })
});
const result = await response.json();
if (!response.ok) throw new Error(result.error || "Request failed");
console.log(result.records);

Authentication

Send Authorization: Bearer YOUR_API_KEY. Keys inherit the account’s access and limits. Invalid or revoked keys return 401. An active Developer plan is checked on every Bearer request, including validators and bank lookups. Free, Pro, expired and not-yet-started Developer subscriptions receive 403, including administrator accounts.

Website login uses an essential session cookie. API integrations should use a Bearer key rather than copying browser cookies. Keep keys out of URLs, screenshots and logs, and revoke keys you no longer need.

API keys and subscription changes

Developer users can keep up to three active keys across all their integrations. At the limit, revoke a key before creating another. Administrators are exempt from the key-count limit, but still need active Developer access for API use and key creation.

Revoke permanently invalidates a key and keeps its entry in your dashboard. Revoked keys cannot be reactivated and do not count toward the limit. Regenerate permanently revokes the old key and creates a new key with the same name; update your integration immediately.

When Developer access expires or changes to another plan, existing keys stop authorizing API requests. Their entries are preserved and can still be revoked through the website. Unrevoked keys work again when Developer access becomes active. Regenerating and creating keys require active Developer access.

Website tools have their own Free, Pro and Developer permissions. Their browser requests do not provide a separate API trial. API integrations use Bearer authentication; do not automate website sessions as a substitute.

Try a request with curl

In a POSIX shell, set GENORY_BASE_URL and GENORY_API_KEY to your site origin and secret key. This example keeps credentials out of the URL. The -i option shows the HTTP status and headers.

curl -i --request POST "$GENORY_BASE_URL/api/profile" \
  --header "Authorization: Bearer $GENORY_API_KEY" \
  --header "Content-Type: application/json" \
  --data '{"country":"DE","amount":1,"fields":["firstName","lastName","email"]}'

Endpoint reference

All paths below are relative to /api. GET parameters belong in the query string. POST requests use a JSON body and Content-Type: application/json.

Request parameters

Business names: /company requires industry or activity (English or German keywords). Optional businessModel: general, consulting, agency, studio, shop, platform, services; audience: general, businesses, consumers, startups, families; style: modern, professional, creative, premium, technical; language: en or de; nameLength: short (one word), medium (two), long (three); location: optional place name. Returns businessName, description, whyItFits, variants and domainIdeas. Availability is not checked. Short names focus on industry/style; longer names include additional brief details. Unknown industries use a keyword-based fallback. This replaces the former company/contact response; profile company fields remain available via /profile.

Common profile fields: firstName, lastName, birthDate, age, street, houseNumber, city, region, postalCode, country, phone, email, username, company, website, jobTitle, department, password, uuid and iban.

Selecting iban also includes banking metadata and validation. Add cardNumber, cardNetwork, cardExpiryDate and cardSecurityCode explicitly for card samples; these are not included by default. Address and phone selections can include related quality metadata.

Choose a bank · Premium

Search /iban/banks?country=DE&q=Hamburg, then pass a returned bankCode to /iban/test-data or /profile. The same selector covers 33 countries. Only banks supported by the extended generator are selectable. Unsupported branches are never combined with a different bank. Postal and city search depend on available address data; this is not a complete bank directory.

API access to the bank catalog and a chosen bank requires active Developer access. The website bank selector is also available with Pro. Account selection is synthetic; choosing a bank does not identify a real customer account.

Card format samples

GET /cards?network=amex or POST /cards with network, amount, country (name locale; default US), and scenario. Website limits are Free 1, Pro 50, Developer 100. API access requires Developer. Pro/Developer also support network=mixed and scenario=expired, invalid-luhn or short-code; the default scenario is valid. Invalid scenarios are explicitly labelled. Supported network values: visa (default), mastercard, amex, discover, jcb, diners, unionpay. Each record includes cardholder, scenario, number, formatted, network, networkName, expiryDate (MM/YY), expiryMonth, expiryYear (four digits), securityCode and securityCodeLabel. Dates are 1–60 months in the future; security codes are strings preserving leading zeroes, with four digits for American Express and three for the other formats. These are representative synthetic formats, not a complete issuer registry or payment-provider sandbox fixtures.

Optional profile fields cardholder (matching the profile name), cardExpiryDate and cardSecurityCode accompany cardNumber and cardNetwork when requested.

Responses and exports

Generator JSON contains a records array. Most generators also return meta; cards return records and refreshed entitlement. Validators return their validation object directly. Do not assume identical response envelopes for every endpoint.

Handle null values when source coverage is missing. IBAN check values are true for passed, false for failed and null for not checked.

Paid requests can use format=csv or format=text. CSV opens in Excel but is not a native .xlsx workbook. Website exports of an existing result do not consume another record; a new API generation request does. The following response is illustrative, with selected fields and metadata abbreviated.

{
  "records": [{
    "label": "Synthetic Test Data",
    "firstName": "Example",
    "lastName": "Person"
  }],
  "meta": { "synthetic": true, "country": "DK", "count": 1 }
}

Allowances and request limits

Developer API and website generation share 500,000 records per 30-day allowance period. Records belong to the account, not the key. Replacing keys does not replenish them. Paid allowance periods begin with paid access. Annual access also replenishes the record allowance every 30 days; unused records do not roll over. Your dashboard shows your remaining records and reset time.

The Developer ceiling is 60 requests per minute per account, shared across keys and website requests; administrators can lower it. Pro website access is limited to 50 records per request and 30 requests per minute. IP and key limits also apply. Guest website limits are enforced jointly by IP address and a signed browser cookie; clearing only the cookie or changing only the IP does not reset the allowance. JSON bodies are limited to 64 KB. Every generated record inside a batch counts as one unit. Validation and bank/coverage lookups do not consume generated-record allowance, but do count toward request-rate limits.

Understand validation and data quality

All 89 registry formats support synthetic generation. The IBAN generator offers 105 countries and territories: 16 territories share the FI, FR or GB format. Territory requests return the actual IBAN country plus requestedRegion and regionNotice; bank and branch details are not targeted to the territory. Country, length, BBAN structure and MOD-97 are always checked; implemented national rules are also applied. The extended generator and bank selector cover 33 countries. Other countries preserve the registry example’s routing fields and include bankWarning when additional validation is incomplete. These outputs may not be fully valid and must not be used for real transactions. The coverage endpoint returns generationCountries, fixtureCountries and fullySupportedGenerationCountries, plus regions (code, name, ibanCountry), regionCount and formatCount. Missing checks remain null; they are never reported as passed.

valid means the base checks pass and no implemented check failed. fullyChecked additionally requires all reported checks to pass. Neither verifies account existence, ownership or third-party acceptance. nationalRuleScope explains where the scheme has no uniform implemented account checksum; individual bank rules may remain outside coverage. Bank addresses are marked verified only when supported by reference sources.

Names inform usernames and email local parts; company names inform email and website domains. Domain registration is not checked. GeoNames supplies linked city, region and available postal data. Some countries have prefixes only or no postal data; inspect postalPrecision. Streets and house numbers are synthetic.

Phone formats use country metadata. Reserved fictional ranges are implemented for Germany, the United Kingdom, the United States, Canada and Australia. Other numbers are not guaranteed to be unassigned.

Card samples satisfy format and Luhn checks. Use your payment provider’s official sandbox fixtures for transactions. BIC validation checks syntax, not registration or bank ownership.

Errors and troubleshooting

Personal support is available only with an active paid Pro or Developer plan. Guest and Free access include documentation and FAQs, but no personal support.

Errors return {"error":"Human-readable message"}. Check the HTTP status before treating a response as generated data.

Do not repeatedly retry 403 responses: check that Developer access is active, then check allowance and request limits. Generation has no idempotency key, so retrying an ambiguous network failure can generate another record and consume allowance again.

Use HTTPS for deployed integrations. Save required fixtures yourself: history stores metadata, not generated profiles. Never submit real customer datasets, credentials or wallet secrets to these tools.