Emcognito vs. Addy.io: Which Alias API Fits a Developer Workflow?

The Short Answer: Emcognito vs. Addy.io for Developers

When evaluating Emcognito vs addy.io for developers, the decision comes down to two architecture requirements: whether you must self-host your forwarding infrastructure, and how many programmatic alias creations your application runs each day. Emcognito is closed source and runs only as a hosted service; if open source or self-hosting is a requirement, addy.io is the better fit. If you want a managed service with a minimal surface area, Emcognito provides a two-endpoint developer REST API with daily creation allowances of 50 aliases per day on Plus and 200 aliases per day on Pro.

Your technical requirements will immediately eliminate one of these platforms:

• Self-hosting and source access: Addy.io publishes its source code and provides Docker configurations for running the forwarding engine on your own servers. Emcognito is closed source, cannot be self-hosted, and runs entirely as a managed platform operated by VectraSEO LLC. Source: Github source.
• API surface complexity: The Emcognito developer API exposes exactly two endpoints on base URL https://api.emcognito.com/v1: listing existing aliases via GET /v1/aliases and creating new aliases via POST /v1/aliases. There is no resource management endpoint for updates; suspending, resuming, and deleting are dashboard operations.
• Domain routing: Emcognito aliases use the shared emcognito.com domain. Custom subdomain support is planned, but custom domains are not available today. If an application architecture demands routing incoming mail through your own registered apex domains, addy.io supports that on its hosted tiers and self-hosted instances.
• Programmatic creation volume: Emcognito meters forwarding bandwidth rather than alias inventory, but caps daily API creation events at 50 aliases per day on Plus ($20/year or $2/month) and 200 aliases per day on Pro ($36/year or $4/month). You can review every quota on the Emcognito pricing page and consult the full specification at the Emcognito developer documentation.

What Each API Actually Exposes

A rigorous email alias API comparison requires analyzing the wire protocol: endpoints, HTTP verbs, payload parameters, response bodies, and authentication mechanisms.

Emcognito API Architecture

The Emcognito v1 developer API focuses strictly on programmatic alias generation and cataloging. It uses standard Bearer token authentication in the HTTP header:

Authorization: Bearer emk_your_key_characters_here_43_chars_long

Every API key begins with the literal prefix emk_ followed by 43 URL-safe characters. There is no live/test environment split, and prefixes like emk_live_ or emk_test_ do not exist. A single key interacts directly with production records associated with your account.

The API surface area contains two endpoints:

1. GET /v1/aliases: Returns a paginated list of aliases owned by the account. Pagination uses cursor navigation via next_cursor and last_key query parameters.
2. POST /v1/aliases: Generates a new forwarding address on emcognito.com. It accepts an optional JSON request body containing six metadata fields:
   • label (string): A short human-readable identifier.
   • note (string): Extended context or purpose for the address.
   • source (string): The origin application, script, or environment generating the call.
   • category (string): An arbitrary tag for grouping addresses.
   • single_use (boolean): Flag indicating whether the address should be deactivated after first delivery.
   • expires_at (integer): Epoch timestamp marking scheduled expiration.

The response contract differs from standard generic CRUD templates. When you issue a POST /v1/aliases call, the service returns HTTP 200 (not 201 Created). The JSON payload wraps the record inside an alias key. There is no top-level identifier or generic data wrapper:

{
  "alias": {
    "id": "9x2k4m1q8p",
    "address": "k8m2p9x4q@emcognito.com",
    "status": "active",
    "created_at": 1774396800,
    "forward_count": 0,
    "label": "staging-checkout",
    "note": "Automated billing test instance",
    "source": "ci-pipeline",
    "category": "testing",
    "single_use": false,
    "expires_at": ""
  }
}

Field data types follow strict parsing rules. The created_at attribute is an integer Unix epoch timestamp, not an ISO-8601 formatted string. If an optional string parameter like note, label, or expires_at is omitted or unset, the API returns an empty string "" rather than null. Client parsers must expect strings for unpopulated metadata fields.

Regarding lifecycle mutation: v1 of the Emcognito API creates and lists aliases (GET and POST /v1/aliases). Suspending, resuming and deleting an alias are one-click dashboard actions today; there is no PATCH or DELETE endpoint yet. If an alias generated by your integration receives abusive traffic, you log into the web interface and select "Pause alias" to instantly sever inbound forwarding.

Addy.io API Architecture

As documented in the addy.io REST API documentation (verified October 2026), addy.io provides an expanded set of API resources that reflects its self-hostable mail engine. Its API covers aliases, recipient addresses, domain management, and account settings.

Developers interacting with addy.io use personal access tokens passed via standard Bearer authorization headers. The resource endpoints follow REST conventions with standard CRUD operations across multiple sub-resources, allowing programmatic creation, updating of alias notes, and toggling of alias states directly via automated scripts. Because addy.io supports bringing your own domains, its endpoints accept requests that specify the domain on which you wish to instantiate an address.

Rate Limits, Daily Caps, and What Your Code Has to Handle

Writing reliable integrations requires understanding rate-limiting behavior, HTTP response codes, and error header contracts. Developer-focused email privacy workflows often fail in continuous integration pipelines if backoff handling makes incorrect assumptions about rate-limiting headers.

Emcognito Burst Limits vs. Daily Creation Caps

Emcognito enforces two independent throttling systems on API usage. Your integration logic must distinguish between them by inspecting both the status code and the response headers:

1. The Short-Term Burst Limiter: Enforced by the edge rate limiter at 60 requests per minute per API key across both GET and POST operations. If your application sends a 61st request within a sixty-second rolling window, the edge layer returns HTTP 429 Too Many Requests. This edge response includes a Retry-After header containing the whole number of seconds until the sliding window resets. A live benchmark recorded on 2026-09-20 showed the 61st call in a minute returned HTTP 429 with retry-after: 60 and a JSON body containing {"message": "Rate limit exceeded"}. If edge capacity fluctuates, a temporary rate-limit HTTP 503 may return with a fixed retry-after: 30 header.
2. The Daily Alias Creation Cap: Enforced by core application code at 50 alias creations per day on Plus and 200 alias creations per day on Pro. This cap counts only POST /v1/aliases requests; calls to GET /v1/aliases do not decrement it. When this daily quota is exhausted, the application layer returns an HTTP 429 with a JSON body: {"message": "Daily alias creation limit reached"}. Crucially, this application-level 429 carries no Retry-After header. The daily counter resets automatically at 00:00 UTC.

Addy.io Rate Limiting Conventions

Based on the addy.io API documentation, addy.io structures rate limits based on account authorization levels, throttling request frequencies over minute and hourly windows. When an application exceeds thresholds on addy.io, it handles HTTP 429 status responses following standard web practices, protecting public instances from automated connection exhaustion.

A Working Create-Alias Call, End to End

To demonstrate practical implementation, here is an end-to-end integration showing a minimal command-line request, a production-grade Python script with dual-layer retry handling, and pagination traversal.

Minimal cURL Request

A direct creation call requires only the Bearer header and a POST payload:

curl -X POST https://api.emcognito.com/v1/aliases \
  -H "Authorization: Bearer emk_your_key_1234567890abcdefghijklmnopqrstuv" \
  -H "Content-Type: application/json" \
  -d '{
    "label": "payment-microservice",
    "source": "billing-daemon",
    "category": "production"
  }'

Python Implementation with Resilient Backoff

This script parses the alias response envelope, reads integer epoch timestamps, correctly handles missing metadata as empty strings, and handles burst limits versus daily application limits based on the official API specification:

import time
import requests
from datetime import datetime, timezone

API_BASE = "https://api.emcognito.com/v1"
API_KEY = "emk_your_key_placeholder_characters_abcdef12345"
HEADERS = {
    "Authorization": f"Bearer {API_KEY}",
    "Content-Type": "application/json"
}
def create_alias(label: str, source: str, category: str = "") -> dict:
    url = f"{API_BASE}/aliases"
    payload = {
        "label": label,
        "source": source,
        "category": category
    }
while True:
    response = requests.post(url, json=payload, headers=HEADERS)

    if response.status_code == 200:
        data = response.json()
        alias_record = data.get("alias", {})
        
        # Epoch created_at parsing
        created_epoch = alias_record.get("created_at", 0)
        created_dt = datetime.fromtimestamp(created_epoch, tz=timezone.utc)
        
        # Unset string fields normalize to empty strings
        address = alias_record.get("address", "")
        assigned_label = alias_record.get("label", "")
        
        print(f"Created: {address} ({assigned_label}) at {created_dt.isoformat()}")
        return alias_record

    elif response.status_code == 429:
        retry_header = response.headers.get("Retry-After")
        
        if retry_header is not None:
            # 60 calls/min burst limiter tripped
            wait_seconds = int(retry_header)
            print(f"Burst limit tripped. Pausing for {wait_seconds} seconds...")
            time.sleep(wait_seconds)
            continue
        else:
            # Daily quota exhausted (no Retry-After header)
            # Resets at 00:00 UTC
            error_msg = response.json().get("message", "Daily creation limit hit")
            raise RuntimeError(
                f"{error_msg}. Daily creation cap exhausted. Suspended until 00:00 UTC."
            )

    elif response.status_code == 503:
        # Service capacity throttle carries fixed 30-second header
        wait_seconds = int(response.headers.get("Retry-After", 30))
        print(f"Service rate-limited. Pausing {wait_seconds} seconds...")
        time.sleep(wait_seconds)
        continue

    else:
        response.raise_for_status()


def list_all_aliases():
    url = f"{API_BASE}/aliases"
    cursor = None
    all_aliases = []
while True:
    params = {}
    if cursor:
        params["next_cursor"] = cursor

    response = requests.get(url, headers=HEADERS, params=params)
    response.raise_for_status()
    data = response.json()

    aliases = data.get("aliases", [])
    all_aliases.extend(aliases)

    cursor = data.get("last_key")
    if not cursor:
        break

return all_aliases

if name == "main":
    new_record = create_alias("test-runner", "local-pytest", "ci")
    print(f"Verified active address: {new_record['address']}")

v1 of the Emcognito API creates and lists aliases (GET and POST /v1/aliases). Suspending, resuming and deleting an alias are one-click dashboard actions today; there is no PATCH or DELETE endpoint yet. Code interacting with the service uses only the supported list and create methods.

Feature Matrix: Emcognito vs. Addy.io

When comparing tools for developer workflows, evaluate the architectural differences between hosted and self-hosted privacy systems. Emcognito is closed source and runs only as a hosted service; if open source or self-hosting is a requirement, addy.io is the better fit.

Where Addy.io Wins, and Where Emcognito Wins

Choosing between these two services involves explicit engineering trade-offs. Neither platform fits every operational scenario.

Where Addy.io Wins

• Self-Hosting and Infrastructure Ownership: If organizational policy requires that zero email transits third-party infrastructure, addy.io is the correct choice. As outlined on the official addy.io GitHub repository, the complete application stack can run inside your own network perimeter using standard container infrastructure.
• Domain Flexibility: If your project requires generating aliases on your own company domains, addy.io supports custom domain routing. Emcognito aliases use the shared emcognito.com domain. Custom subdomain support is planned, but custom domains are not available today.
• Full Programmatic Lifecycle Control: If your application must dynamically deactivate, re-activate, and destroy forwarding routes based on internal database triggers without manual intervention, addy.io provides programmatic endpoints for updating alias state.

Where Emcognito Wins

• Zero Infrastructure Maintenance: You do not manage Postfix configurations, SPF/DKIM validation rules, server IP reputations, or container patch cycles. The service functions as a durable, reliable forwarding utility directly out of the box.
• Minimal Operational Overhead: A two-endpoint REST interface without complex state synchronization or authentication scopes means an engineer can build, test, and deploy a complete integration in an afternoon. There are no test environments to sync or token refreshes to manage.
• Clear Security Boundaries: Emcognito is not a zero-knowledge service. It does not read or analyse message contents, or retain them after delivery, apart from a brief hold on mail that arrives over your monthly forward cap, but it necessarily handles mail in readable form in order to deliver it. Emcognito forwards mail over TLS-encrypted transport and does not read message contents or retain them after delivery, apart from a brief hold on mail that arrives over your monthly forward cap, but it is not end-to-end encrypted. For content confidentiality, pair it with an encrypted mailbox such as Proton Mail or Tuta.
• Disciplined Data Handling: Emcognito collects no personal information beyond a destination address and does not retain message bodies after delivery, apart from a brief hold on mail that arrives over your monthly forward cap, but it keeps the delivery and operational logs any mail service needs. That is data minimisation, not a no-log policy.
• Service Continuity: Emcognito publishes a wind-down commitment: advance notice before a planned shutdown and alias export so accounts can be migrated, on a best-efforts basis. It is not a contractual guarantee.

Pricing for Developers: What the Caps Cost You

Emcognito provides unlimited anonymous email aliases and meters accounts primarily by monthly forwarded email volume, while reserving outbound messaging capabilities and developer API access for paid subscriptions. Customers evaluate tiers based on the annual term, which represents the standard operational commitment.

Plan pricing is published directly on the Emcognito pricing schedule:

• Emcognito Pro: $36 per year (or $4 per month). Pro yearly is three months free and is the term customers actually buy. This tier includes 15,000 forwarded messages per month, outbound mail composition from any alias at an elevated daily send cap, and the developer API capped at 200 alias creations per day. Source: Emcognito source.
• Emcognito Plus: $20 per year (or $2 per month). This tier provides 2,500 forwarded messages per month, outbound mail composition from any alias, removal of sponsor cards on forwarded messages, and the developer API capped at 50 alias creations per day.
• Emcognito Free: no payment and no credit card required. Free provides unlimited anonymous email aliases and 100 forwarded messages per month (which can increase to at most 200 through referral credits). Free accounts can view inbound mail logs and create aliases from the web dashboard (capped at 200 per day), but the developer API is not included on Free. Until November 3, 2026, Free accounts can reply to forwarded mail with Reply securely in the delivery log; from that date replying is a Plus and Pro feature. Replying from your own mail app is a Plus and Pro feature. Free accounts cannot compose brand-new outbound mail.

What is metered across paid accounts is forwarded email volume, not alias inventory. Your account can store tens of thousands of dormant aliases indefinitely on any tier without paying per-alias maintenance charges.

Both Plus and Pro plans offer a 7-day free trial on either monthly or annual billing. You supply payment details at checkout, and no charges process until the trial window concludes. Signup is entirely passwordless: authentication relies on an emailed magic link sent to your destination mailbox, avoiding account credential overhead or third-party identity dependencies.

Outbound Sending Mechanics

For applications where a programmatic alias receives communications that require an operational response, outbound routing behavior is critical. On Plus and Pro you can hit Reply in your own mail app (Gmail, Outlook, Apple Mail) on a forwarded message, and Emcognito sends the reply from the alias. It is accepted only from the mailbox you sign in with, and each reply uses one monthly send. On Free, replying from your mail app is a Plus feature; Free accounts can reply from the delivery log with Reply securely until November 3, 2026, after which Reply securely is Plus and Pro only.

Replies initiated from an external mail app must transit from the account's registered sign-in inbox with passing Sender Policy Framework (SPF) validation and an aligned DomainKeys Identified Mail (DKIM) signature as defined under standard internet mail protocols (RFC 7208 and RFC 6376). Messages forwarded prior to October 5, 2026 do not carry routing addresses for mail-app replies.

Outbound composition has a daily send cap: 20 messages per day on Plus and 100 messages per day on Pro, which ramps up over the first 7 days of service. Hitting this daily composition cap does not interrupt inbound email forwarding, but every composed message consumes one unit from your aggregate monthly forwarding allowance.

Choosing: A Decision Checklist for Your Stack

Use this technical checklist to determine whether Emcognito or addy.io fits your engineering requirements:

1. Do you require self-hosted source code? If yes, select addy.io. Emcognito is closed source and runs only as a hosted platform.
2. Does your application generate more than 200 aliases per day? If yes, a single Emcognito Pro account will not support your throughput, as API creation is strictly capped at 200 per day. You would need to manage creation rate queues or deploy your own addy.io cluster.
3. Do you need programmatic address deactivation via API? v1 of the Emcognito API creates and lists aliases (GET and POST /v1/aliases). Suspending, resuming and deleting an alias are one-click dashboard actions today; there is no PATCH or DELETE endpoint yet. If automated deactivation via an API call is required, addy.io provides this functionality.
4. Do you need custom domains? Emcognito aliases use the shared emcognito.com domain. Custom subdomain support is planned, but custom domains are not available today. If your mail routing depends on external domains, addy.io provides that support.
5. Are you generating aliases interactively on web forms? If your workflow is developer-adjacent (e.g., testing signup forms manually rather than scripting), the Emcognito Chrome browser extension injects alias creation triggers directly into browser input fields.
6. Do your automated addresses require outbound conversational replies? If real humans on your engineering team need to reply to inbound alert emails using standard mail clients, learn how to reply from your alias using Emcognito Plus or Pro, which routes your response through the alias while protecting your backend infrastructure inbox.

Frequently Asked Questions

Does the Emcognito API have a sandbox or test key?

No. Emcognito does not feature a sandbox environment or test key mode. There is no live/test split. Keys use the prefix emk_ followed by 43 URL-safe characters. Every call executed against https://api.emcognito.com/v1 creates real, production-ready routing records associated with your account.

Can I suspend or delete an alias through the Emcognito API?

Not in v1. v1 of the Emcognito API creates and lists aliases (GET and POST /v1/aliases). Suspending, resuming and deleting an alias are one-click dashboard actions today; there is no PATCH or DELETE endpoint yet. Pausing an alias via the web interface takes effect immediately, while deletion requires a confirmation prompt.

What happens when I hit the daily alias-creation cap?

When you reach your daily creation quota (50 aliases per day on Plus or 200 aliases per day on Pro), the application returns an HTTP 429 status code with the JSON body {"message": "Daily alias creation limit reached"}. This response contains no Retry-After header. The quota counter resets at 00:00 UTC.

Does the Emcognito developer API send rate-limit headers?

POST /v1/aliases returns HTTP 200 with the new alias under "alias". The burst limit is 60 requests a minute per key; its 429 carries a Retry-After header giving the seconds until the window resets. The daily alias-creation cap (50 on Plus, 200 on Pro) resets at 00:00 UTC and its 429 carries no Retry-After. Emcognito sends no X-RateLimit-* headers.

Is Emcognito open source or self-hostable?

No. Emcognito is closed source and runs only as a hosted service; if open source or self-hosting is a requirement, addy.io is the better fit. Emcognito is managed by VectraSEO LLC, handling MTA infrastructure, SPF/DKIM delivery configuration, and inbound forwarding operations.

The One Next Step

Read the developer alias API reference at https://emcognito.com/developers, create a key, and test POST /v1/aliases against your own workflow. The developer API is included with Plus at $20/year (50 aliases/day) and Pro at $36/year (200 aliases/day).