Five products · live in production

Sign-in, email, waitlists, social feeds and web scraping, ready to plug into your app. Your AI agents can use them too, with only the access you give them.

Five products, already built.

Use one or all five. Each has its own API, docs and SDK. One account covers them all.

  1. Open a workspace. Sign in to the console. All five products live in it.

  2. Create an API key. One key works for all five, and you choose what it can do.

  3. Install and call. npm install productcraft, then pc.auth, pc.mail, pc.waitlist, pc.social or pc.trawl.

Auth

Passkeys, two-factor and organizations, without writing auth.

Add Apple, Google or GitHub sign-in. Setup checks your credentials as you save them. Move your users over from Auth0 or your own database, passwords included, so nobody has to reset.

  • Roles your backend can trust. Each user's organization and role travel in their sign-in token, so your API can check them without a lookup.
  • An audit log you can export. Every app keeps a log that nobody can edit.

A checklist confirms each setup step, and Try sign-in tests a real sign-in against your app.

Mail

Send email from your domain, not ours.

Write templates with a live preview, then send them with one API call.

A delivered demo email's record in the console: Email, Delivered, sent from hello@demo-lp-northwind.productcraft.co to the Amazon SES mailbox simulator, subject Welcome to Northwind Tea, Ada, with its id, timestamps, sending domain and transport, then its timeline: queued, sent, delivered. Demo data.

Demo: Ada's welcome email, delivered.

Proof it arrived. Every message keeps its delivery timeline. Addresses that bounce are blocked from later sends.

  • A new broadcast in the console with a segment and a topic chosen, and its reach: 12 people would receive it now. Demo data; not saved and never sent.

    Broadcasts. Pick a segment or a topic, see how many people it will reach, then send now or on a schedule.

  • A demo sending domain's DNS records: the DKIM key and the SPF return-path records, each marked Verified. Demo data.

    Your domain, verified. Add the DNS records once and every email is signed as you (DKIM), so receiving servers know it came from you.

  • A new segment's rule, Email contains @example.com, with its live count: 12 contacts match, 12 consented. Demo data.

    Segments that stay current. Define them with rules on contact fields, and preview who matches before you save.

  • Retries never send twice. If your code sends the same request twice, the email still goes out once.
  • Use your own email provider. Send through any SMTP service, per workspace or per domain.

ProductCraft sends its own email through Mail.

Trawl

Describe the data. Get JSON that matches.

Give it a page, a one-sentence description and a JSON Schema. A browser agent reads the page and returns JSON that fits. Results arrive on a signed webhook.

  1. Describe it The schema and the sentence you send.

    The five most recent releases: package name and version.

    {
      "type": "object",
      "properties": {
        "releases": {
          "type": "array",
          "maxItems": 5,
          "items": {
            "type": "object",
            "properties": {
              "package": {
                "type": "string"
              },
              "version": {
                "type": "string"
              }
            },
            "required": [
              "package",
              "version"
            ]
          }
        }
      },
      "required": [
        "releases"
      ]
    }
  2. Get JSON The data the agent returned, checked against your schema.

    {
      "releases": [
        {
          "package": "productcraft",
          "version": "0.3.1"
        },
        {
          "package": "@productcraft/social",
          "version": "1.0.0"
        },
        {
          "package": "productcraft",
          "version": "0.3.0"
        },
        {
          "package": "@productcraft/waitlist",
          "version": "0.2.0"
        },
        {
          "package": "@productcraft/trawl",
          "version": "0.2.0"
        }
      ]
    }
package maps to productcraftversion maps to 0.3.1

From the first signup to the first feed.

Waitlist

Signups that don't live in a spreadsheet.

A demo waitlist's top referrals: Grace Hopper with 6 referrals, Alan Turing with 4 and Katherine Johnson with 2; the referral boost moved each of them to the front of the line, where they are tied at #1. Demo data.

Demo: Grace, Alan and Katherine brought in twelve.

Referrals and A/B tests. Places in line, a referral leaderboard and a different version per landing page.

  • Works from a static page. Your signup form posts straight to it, with no backend or API key. The console gives you the snippet.
  • Approve, then invite people into your app. Or download the list as a CSV.

Social

Feeds, follows and ranking you don't have to build.

A demo Social community's analytics, Northwind Tea Club: 6 members, 3 posts and 4 comments, each with the last 7 days. Demo data; the open-flags total and the moderation log are cropped out.

Demo: the Northwind Tea Club community.

Community analytics. Members, posts, comments and reported content, each with its change over the last 7 days.

  • Use it on its own. No ProductCraft Auth app required.
  • Stories, DMs and video. Stories with polls and close-friends lists. Video uploads up to 512 MB, ready to stream.

One workspace

One workspace. One key. Five products.

Everything you create lives in one workspace, and one sign-in opens all five products in the console.

sdk
@productcraft/auth · mail · waitlist · social · trawl, plus the productcraft umbrella. Node.js / TypeScript, server-side, MIT.
webhooks
Signed webhooks on all five products, each with Send test, a 30-day event log and replay.

signin.ts

import { ProductCraft } from "productcraft";

// Sign-in acts for the end user: no API key is sent
const pc = new ProductCraft();

const consumer = pc.auth.consumer("my-app");
const tokens = await consumer.signin({
  identifier: "alice@example.com",
  password: "...",
});
import { ProductCraft } from "productcraft";

// Public route: no API key is sent
const pc = new ProductCraft();

const consumer = pc.auth.consumer("my-app");
const tokens = await consumer.signin({
  identifier: "alice@example.com",
  password: "...",
});

200 OK

{
  "access_token": "eyJ…",
  "refresh_token": "eyJ…",
  "token_type": "Bearer",
  "expires_in": 3600
}

Plain REST, with optional typed SDKs for your server. The docs, the SDKs and the MCP server are all built from one OpenAPI spec.

PoliciesPolicies decide what every key and every agent can touch.
The editor for a demo workspace policy, demo-lp-readonly-support: its name and its description, “Support can read mail, waitlist and auth data; nothing can be deleted.”, above the Policy statements header; the statements are cropped out. Demo data.
The consent screen at auth.productcraft.co for an MCP client: Mail and Waitlist ticked among the five products, the Read-only preset, which changes nothing, then Deny and Allow access. Demo session; the client name and the workspace list above are cropped out.

From your editor

Claude, Cursor and VS Code can work in your workspace.

An MCP server at mcp.productcraft.co. You approve the connection in the browser, a policy preset caps what it may do, and every call lands in the audit log.

claude mcp add --transport http productcraft 'https://mcp.productcraft.co/mcp' # then, inside Claude Code: /mcp # pick "productcraft" and follow the browser prompt
How many people are on the demo-lp-launch waitlist, how many came through a referral, and who are the first three in the queue?
waitlist_list_waitlists {"limit": 50}
<<<UNTRUSTED-DATA tool="waitlist_list_waitlists">
"slug": "demo-lp-launch",
"display_name": "<<untrusted> Northwind Tea: autumn menu <untrusted>>",
waitlist_get_waitlist_analytics {"waitlist_id": "…"}
<<<UNTRUSTED-DATA tool="waitlist_get_waitlist_analytics">
"total_entries": 16,
"viral_coefficient": 0.75,
"referred_count": 12,
waitlist_list_waitlist_entries {"waitlist_id": "…", "limit": 5, "is_test": false}
<<<UNTRUSTED-DATA tool="waitlist_list_waitlist_entries">
"email": "ada@example.com",
"email": "grace@example.com",
"email": "alan@example.com",

demo-lp-launch ("Northwind Tea: autumn menu") has 16 people on it, not counting test signups. All 16 are approved. All of them signed up today, 2026-11-05.

12 of the 16 came through a referral (about 75%). Those referrals came from 3 people:

- Grace Hopper: 6 referrals

- Alan Turing: 4

- Katherine Johnson: 2

First three in the queue:

1. Ada Lovelace (ada@example.com)

2. Grace Hopper (grace@example.com)

3. Alan Turing (alan@example.com), who was referred by Grace

Referral rewards have moved people up the queue. Ada, Grace, Alan and Katherine Johnson (4th) all now share effective position 1. So if you're ranking by effective position, those four are tied at the front, and the original signup order is what breaks the tie.

  • Presets: readonly, mail, support, full. No preset lets an agent give itself more access.
  • Approve only the products it needs. Within those, it can do whatever your policy allows.

Note what the command leaves out: no token, no key, no secret. The URL is the only setting.

Connect your editor

Changelog

Shipped, dated, linked.

Every entry is a production deploy.

Get started

The parts every app needs are done. Build the rest.

Start with the product that brought you here. The other four use the same key.

Package manager
npm install productcraftpnpm add productcraftyarn add productcraft

Each product has a free tier large enough to ship a side project on. Pricing is coming soon.