twenty-app-intake 0.4.0 → 0.5.0

package/README.md

@@ -203,6 +203,18 @@ Intake accepts any valid JSON. No required fields.
 | `utm_source/medium/campaign/content/term` | Note (always) |
 | `message`, `description`, `notes`, `comments`, `analysis` | Note (always) |
 
+Key matching ignores case and separator style, so `Email`, `email`, `E-Mail`, `EMAIL`
+and `emailAddress` all reach the same mapping. Nested payloads are flattened first —
+`{"contact": {"first_name": "Jane"}}` becomes `contactFirstName`.
+
+> **Fixed in 0.5.0.** A key that merely *started* with a capital — `Email`, `Phone`,
+> `First Name`, the default labels most form builders send — missed the built-in map
+> entirely and fell through to passthrough, producing a person with an `extEmail`
+> column and no email address on the record. Because deduplication runs on the email,
+> every later submission from that person created another copy. If a source of yours
+> sends capitalised keys, look for `extEmail`, `extPhone` and `extFirstName` columns
+> left behind by earlier runs.
+
 Unknown fields get an `ext_` prefix and are created as custom fields the first time they appear.
 
 ---
@@ -213,15 +225,64 @@ Add `IntakeFieldRule` records to extend or override the built-in map for a speci
 
 | Field | Description |
 |---|---|
-| `inputPattern` | Exact key name or JavaScript regex |
+| `inputPattern` | Exact key name or JavaScript regex — see [How a pattern is matched](#how-a-pattern-is-matched) |
 | `canonicalName` | Target field in Twenty. An `ext`-prefixed name (`extBudget`) is created automatically; any other name must already exist on the target object |
-| `fieldType` | `TEXT`, `NUMBER`, `LINKS`, `EMAILS`, `PHONES`, `BOOLEAN`, `DATE_TIME`, `CURRENCY`, `NOTE`, or `SKIP` |
+| `fieldType` | `TEXT`, `NUMBER`, `BOOLEAN`, `DATE`, `DATE_TIME`, `CURRENCY`, `LINKS`, `EMAILS`, `PHONES`, `RICH_TEXT`, `RAW_JSON`, `NOTE`, or `SKIP` |
 | `targetObject` | `AUTO` (default), `PERSON`, `COMPANY`, or `OPPORTUNITY` |
 | `mergeStrategy` | `INHERIT` (default), `PRESERVE`, or `NEWEST_WINS` — see [Updating existing records](#updating-existing-records) |
 | `priority` | Higher = checked first (0–100) |
 
 Rules with no source linked apply globally across all sources.
 
+### Which mapping wins
+
+Every incoming key is resolved in this order:
+
+1. **Your rules**, highest `priority` first
+2. **The built-in map**
+3. **Passthrough** — an `ext`-prefixed custom field with an auto-detected type
+
+A rule beats the built-in map. That is what makes a rule worth configuring: it is
+how `utm_source` becomes a real field instead of a line in the note, and how a
+`website` goes somewhere other than the company's domain.
+
+> **Changed in 0.5.0.** Before 0.5.0 the built-in map was consulted *first*, so a
+> rule naming any of the 100+ built-in keys was silently ignored — the opposite of
+> what this page has always described. If you wrote a rule against a built-in key
+> and worked around it doing nothing, that workaround is now live. Check any rule
+> matching `utm_*`, `website`, `url`, `domain`, `message`, `notes`, `city`, `state`
+> or `country` before upgrading.
+
+**One exception.** A rule cannot take a contact's `name`, `email` or `phone` away
+from the contact — it may restate the mapping and set the type, target and merge
+strategy, but it cannot send the value to a different field, to the note, or to the
+bin. A person with no email cannot be found again, so the next submission from the
+same address would create a duplicate, and the one after that another. When a rule
+is turned away for this reason the ingest log says so by name.
+
+To put a second address or a company switchboard somewhere of your own, match a key
+the built-in map does not already own — `company_email`, `alt_phone`, `direct_line`.
+Those behave like any other key.
+
+### How a pattern is matched
+
+`inputPattern` is tried as an exact key name first, then as a JavaScript regex
+(case-insensitive). Both are tested against **both spellings of the key**: the
+literal key as it arrived, and its `snake_case` form.
+
+Nested payloads are flattened to camelCase before rules run, so `{"lead": {"id": 1}}`
+arrives as `leadId`. Writing `^lead_id$` or `^leadId$` therefore both work, and so
+does the bare string `lead_id`.
+
+> **Fixed in 0.5.0.** Patterns were previously tested against the camelCased key
+> only, so `^lead_id$` never matched anything while the bare string `lead_id` matched
+> fine. Patterns without underscores — `budget`, `amount`, `gclid` — were unaffected,
+> which made the failure look arbitrary. A regex that was silently dead may now start
+> matching; check any pattern you wrote with an underscore in it.
+
+A pattern that is not valid regex still works as an exact key match rather than
+being discarded.
+
 ### Writing to the Opportunity
 
 Deal attributes — the service someone asked for, the budget they stated, your own
@@ -251,6 +312,36 @@ in a follow-up call, so a rejected field never costs you the Opportunity itself.
 A field routed to the Opportunity by a source that does not create one falls back to
 the primary record, with a warning on the log.
 
+### Companies from email domains
+
+**Intake never reads an employer out of an email address.** A company is created
+only when the payload actually names one (`company`, `business`, `organization`) or
+gives a domain of its own (`website`, `domain`, `url`). A lead from
+`jane@gmail.com` with no company field creates a person and no company at all.
+
+This is deliberate. Most small-business enquiries arrive from a consumer mailbox, so
+a webhook that inferred companies from email domains would fill the Companies table
+with mail hosts — a company called "gmail.com" with forty unrelated people filed
+under it. If a mail provider arrives in a *website* field, Intake leaves it off the
+company record and says so in the ingest log rather than storing it.
+
+> **Twenty itself does infer companies this way, and it is on by default.** Every new
+> workspace is seeded with a workflow called **"Create company when adding a new
+> person"**, which fires on any person whose `emails` field is written — including
+> people created through the REST and GraphQL APIs, and therefore including everything
+> Intake writes. It extracts the domain from the person's email, creates a company for
+> it if none matches, and then **updates the person's `companyId` to point at it** —
+> overwriting the company Intake had already linked them to.
+>
+> The symptom is one lead producing two companies: the correct one on the Opportunity,
+> and a domain-named one on the Person. Twenty's workflow skips a list of common
+> personal domains (`gmail.com`, `yahoo.com`, `outlook.com`, `icloud.com` and similar),
+> so it shows up on leads from business addresses.
+>
+> Nothing an app can send suppresses it — passing an explicit `companyId` does not.
+> If you want Intake's company linkage to stand, open **Settings → Workflows**, find
+> "Create company when adding a new person", and deactivate it.
+
 ### Fields that cannot be written
 
 A rule pointing at a field that does not exist — and is not `ext`-prefixed, so cannot

package/manifest.json

@@ -85,9 +85,9 @@
       "public/cover.generated.png"
     ],
     "defaultRoleUniversalIdentifier": "3dd2cdb0-32c7-44b4-9f7b-0a9c667ec249",
-    "aboutDescription": "<div align=\"center\">\n  <img src=\"./public/logo.svg\" width=\"80\" height=\"80\" alt=\"Intake logo\" />\n  <h1>Intake</h1>\n  <p><strong>The missing ingestion layer for Twenty CRM.</strong><br/>\n  Wire any form, webhook, or data source to Twenty. Leads land clean — every time.</p>\n\n  [![npm version](https://img.shields.io/npm/v/twenty-app-intake?color=0F172A&labelColor=334155&label=npm)](https://www.npmjs.com/package/twenty-app-intake)\n  [![Twenty](https://img.shields.io/badge/Twenty-%3E%3D2.26.0-0F172A?labelColor=334155)](https://twenty.com)\n  [![Tests](https://img.shields.io/badge/tests-68%20passing-22c55e?labelColor=334155)](https://github.com/FranciscoContreras/twenty-app-intake/actions)\n  [![License](https://img.shields.io/badge/license-MIT-0F172A?labelColor=334155)](./LICENSE)\n  [![Website](https://img.shields.io/badge/website-wearemachina.com-0F172A?labelColor=334155)](https://wearemachina.com)\n\n  <sub>Built by <a href=\"https://wearemachina.com\"><strong>Machina</strong></a></sub>\n</div>\n\n---\n\n## The problem\n\nYour contact forms, pipeline scrapers, and partner APIs each have their own field names. `phone_number` here, `phoneNumber` there, `tel` somewhere else. Half the time a new field appears and breaks your Zap. The other half, someone enters a duplicate that your team has to clean manually.\n\nIntake handles all of it automatically.\n\n## What it does\n\nSend any JSON payload to Intake's webhook. It figures out the rest.\n\n```bash\ncurl -X POST https://your-crm.com/s/intake/getting-started \\\n  -H \"Content-Type: application/json\" \\\n  -d '{\n    \"first_name\": \"Jane\",\n    \"last_name\":  \"Doe\",\n    \"email\":      \"jane@acme.com\",\n    \"phone_number\": \"415-555-0199\",\n    \"company\":    \"Acme Inc\",\n    \"message\":    \"Need a new website by Q3.\",\n    \"utm_source\": \"google\",\n    \"budget\":     \"25000\"\n  }'\n```\n\n**What Twenty gets:**\n- ✅ Person record — Jane Doe, jane@acme.com, +1 415 555 0199\n- ✅ Company record — Acme Inc (linked to Jane)\n- ✅ Opportunity — \"Getting Started — Jane Doe\", stage: NEW\n- ✅ Note — message + UTM source, formatted and attached\n- ✅ Custom field `extBudget` auto-created on Person (first time only)\n\nNo Zaps. No middleware. No broken automations when your form adds a field.\n\n---\n\n## How it works\n\n```\nAny JSON payload\n      │\n      ▼\n① Normalize    phone_number → phone, emailAddress → email, firstName + lastName → name\n      │\n      ▼\n② Classify     short values → CRM fields │ prose / UTMs → note\n      │\n      ▼\n③ Extend       unknown fields → auto-create ext custom fields on Person, Company or Opportunity\n      │\n      ▼\n④ Deduplicate  match by email (Person) or domain (Company) before creating anything\n      │\n      ▼\n⑤ Ingest       Person + Company + Opportunity + Note — one webhook, the full chain\n      │\n      ▼\n⑥ Log          every ingestion recorded in IntakeLog with status, timing, field counts\n```\n\n---\n\n## Get started\n\n### 1. Install\n\nFrom the Twenty marketplace in **Settings → Applications**, search for **Intake** and install.\n\nOn fresh install, Intake automatically creates a \"Getting Started\" source with a ready-to-use webhook URL.\n\n### 2. Register a source\n\n```bash\ncurl -X POST https://your-crm.com/s/intake/sources/register \\\n  -H \"Authorization: Bearer YOUR_API_KEY\" \\\n  -H \"Content-Type: application/json\" \\\n  -d '{\n    \"name\": \"Contact Form\",\n    \"slug\": \"contact-form\",\n    \"targetObject\": \"AUTO\"\n  }'\n```\n\n```json\n{\n  \"webhookUrl\": \"https://your-crm.com/s/intake/contact-form\",\n  \"secret\": \"wh_live_abc123...\"\n}\n```\n\n### 3. Test without writing anything\n\n```bash\ncurl -X POST https://your-crm.com/s/intake/contact-form/test \\\n  -H \"Content-Type: application/json\" \\\n  -d '{\"first_name\":\"Jane\",\"email\":\"jane@co.com\",\"budget\":\"15000\"}'\n```\n\nReturns a structured diff of what *would* happen, without touching the CRM: per object\nwhether it would be **created or updated**, which existing record it matched and on\nwhat, what each field would do to the value already there, and which fields do not\nexist yet and would be added to the schema. Plus the spam score the payload would get.\n\n```jsonc\n{\n  \"dryRun\": true,\n  \"diff\": {\n    \"objects\": [{\n      \"object\": \"person\",\n      \"operation\": \"update\",\n      \"recordId\": \"8f21…\",\n      \"matchedBy\": { \"field\": \"emails.primaryEmail\", \"value\": \"jane@co.com\" },\n      \"fields\": [\n        { \"name\": \"name\", \"status\": \"preserved\", \"existing\": {…}, \"incoming\": {…} },\n        { \"name\": \"phones\", \"status\": \"fill-empty\", \"incoming\": {…} },\n        { \"name\": \"extBudget\", \"status\": \"create\", \"fieldWouldBeCreated\": true }\n      ],\n      \"fieldsToCreate\": [{ \"name\": \"extBudget\", \"type\": \"NUMBER\" }]\n    }]\n  }\n}\n```\n\nBecause it is machine-readable, this is the gate to put in front of live traffic —\nassert on it in a deployment check rather than reading it by eye.\n\n---\n\n## Payload formats\n\nIntake accepts any valid JSON. No required fields.\n\n**Flat (contact form):**\n```json\n{\n  \"first_name\": \"Jane\",\n  \"email\": \"jane@acme.com\",\n  \"company\": \"Acme\",\n  \"message\": \"Looking for a full rebrand.\",\n  \"utm_source\": \"google\"\n}\n```\n\n**Structured (pipeline app):**\n```json\n{\n  \"company\": {\n    \"name\": \"Acme Plumbing\",\n    \"domainName\": { \"primaryLinkUrl\": \"https://acmeplumbing.com\" },\n    \"address\": { \"addressCity\": \"San Jose\", \"addressState\": \"CA\" }\n  },\n  \"person\": {\n    \"name\": { \"firstName\": \"John\", \"lastName\": \"Smith\" },\n    \"emails\": { \"primaryEmail\": \"john@acmeplumbing.com\" }\n  },\n  \"google_rating\": 4.7,\n  \"review_count\": 143,\n  \"analysis\": \"Strong reviews, outdated website.\"\n}\n```\n\n**Arbitrary nested:**\n```json\n{\n  \"submitted_by\": { \"full_name\": \"Alex Thompson\", \"contact_email\": \"alex@co.com\" },\n  \"project\": { \"type\": \"SaaS Dashboard\", \"budget\": \"15k\" },\n  \"referrer\": \"behance\"\n}\n```\n\n---\n\n## Built-in field normalization\n\n100+ mappings ship by default. Some highlights:\n\n| Incoming key | Twenty field |\n|---|---|\n| `phone`, `phone_number`, `phoneNumber`, `tel`, `mobile`, `cell` | `phones.primaryPhoneNumber` |\n| `email`, `email_address`, `contact_email` | `emails.primaryEmail` |\n| `first_name`, `firstName`, `fname` | `name.firstName` |\n| `last_name`, `lastName`, `surname` | `name.lastName` |\n| `name`, `full_name`, `fullName` | `name` (auto-split) |\n| `company`, `company_name`, `business`, `organization` | Company record |\n| `website`, `url`, `domain`, `homepage` | `domainName.primaryLinkUrl` |\n| `utm_source/medium/campaign/content/term` | Note (always) |\n| `message`, `description`, `notes`, `comments`, `analysis` | Note (always) |\n\nUnknown fields get an `ext_` prefix and are created as custom fields the first time they appear.\n\n---\n\n## Custom field rules\n\nAdd `IntakeFieldRule` records to extend or override the built-in map for a specific source or globally:\n\n| Field | Description |\n|---|---|\n| `inputPattern` | Exact key name or JavaScript regex |\n| `canonicalName` | Target field in Twenty. An `ext`-prefixed name (`extBudget`) is created automatically; any other name must already exist on the target object |\n| `fieldType` | `TEXT`, `NUMBER`, `LINKS`, `EMAILS`, `PHONES`, `BOOLEAN`, `DATE_TIME`, `CURRENCY`, `NOTE`, or `SKIP` |\n| `targetObject` | `AUTO` (default), `PERSON`, `COMPANY`, or `OPPORTUNITY` |\n| `mergeStrategy` | `INHERIT` (default), `PRESERVE`, or `NEWEST_WINS` — see [Updating existing records](#updating-existing-records) |\n| `priority` | Higher = checked first (0–100) |\n\nRules with no source linked apply globally across all sources.\n\n### Writing to the Opportunity\n\nDeal attributes — the service someone asked for, the budget they stated, your own\nlead id — belong on the Opportunity, not the contact. Two ways to put them there:\n\n**A prefix, no configuration.** Any incoming key beginning `opportunity_`, `opp_`\nor `deal_` is routed to the deal, and the prefix is stripped before the field is\nnamed — `opportunity_budget` becomes `extBudget` on the Opportunity.\n\n```jsonc\n{ \"email\": \"jane@acme.com\", \"opportunity_budget\": \"25000\", \"opportunity_service\": \"SEO\" }\n```\n\n**A rule, for keys you cannot rename.** Set `targetObject: OPPORTUNITY` on the rule\nand point `canonicalName` at the field you want written:\n\n| inputPattern | canonicalName | targetObject | fieldType |\n|---|---|---|---|\n| `service` | `machinaService` | `OPPORTUNITY` | `TEXT` |\n| `budget` | `amount` | `OPPORTUNITY` | `CURRENCY` |\n\n`amount` and `closeDate` are standard Opportunity fields and are set as the deal is\ncreated; `amount` accepts a bare number or a written figure (`\"$25,000/mo\"`) and is\nconverted to Twenty's currency micros. Everything else is written as a custom field\nin a follow-up call, so a rejected field never costs you the Opportunity itself.\n\nA field routed to the Opportunity by a source that does not create one falls back to\nthe primary record, with a warning on the log.\n\n### Fields that cannot be written\n\nA rule pointing at a field that does not exist — and is not `ext`-prefixed, so cannot\nbe auto-created — has its value routed to the note, with a warning naming the field.\nIt is not counted as matched. Create the field in Twenty first, or rename the rule's\n`canonicalName` to use an `ext` prefix.\n\n---\n\n## Source configuration\n\nEach `IntakeSource` record controls:\n\n| Field | Default | Description |\n|---|---|---|\n| `targetObject` | `AUTO` | `PERSON`, `COMPANY`, or auto-detect |\n| `webhookSecret` | — | HMAC-SHA256 signing secret |\n| `createOpportunity` | `true` | Auto-create Opportunity per ingestion |\n| `opportunityNameTemplate` | `{{source}} — {{firstName}} {{lastName}}` | Supports `{{source}}`, `{{firstName}}`, `{{lastName}}`, `{{email}}`, `{{company}}` |\n| `status` | `ACTIVE` | Pause a source without deleting it |\n| `mergePolicy` | — | Overrides `INTAKE_MERGE_POLICY` for this source |\n| `honeypotField` | — | Overrides `INTAKE_HONEYPOT_FIELD` for this source |\n| `expectedCadenceHours` | — | How long this source may go quiet before it counts as silent |\n| `alertWebhookUrl` | — | Posted to once when this source falls silent |\n\n---\n\n## Workspace settings\n\nConfigurable from **Settings → Applications → Intake → Custom**:\n\n| Setting | Default | Description |\n|---|---|---|\n| `INTAKE_APP_LABEL` | `Intake` | Name used in note titles and opportunity names |\n| `INTAKE_DEFAULT_OPP_STAGE` | `NEW` | Stage for auto-created Opportunities |\n| `INTAKE_FIELD_CREATION_ENABLED` | `true` | Toggle auto-schema extension |\n| `INTAKE_MAX_EXT_FIELDS` | `50` | Cap on custom fields per object |\n| `INTAKE_DEDUP_WINDOW_MINUTES` | `5` | Duplicate suppression window |\n| `INTAKE_REQUIRE_HMAC` | `false` | Enforce signed webhooks globally |\n| `INTAKE_MERGE_POLICY` | `PRESERVE` | What an update does to a field that already has a value |\n| `INTAKE_SPAM_FILTER_ENABLED` | `false` | Score payloads and quarantine at the threshold |\n| `INTAKE_SPAM_SCORE_THRESHOLD` | `5` | Score at which a payload is held |\n| `INTAKE_HONEYPOT_FIELD` | — | Name of a hidden form field that quarantines when filled |\n| `INTAKE_RAW_PAYLOAD_RETENTION` | `FULL` | `FULL` keeps payloads for replay; `NONE` keeps none |\n| `INTAKE_RAW_PAYLOAD_MAX_BYTES` | `65000` | Largest payload stored for replay |\n| `INTAKE_REPLAY_MAX_BATCH` | `50` | Cap on one bulk replay (hard ceiling 500) |\n\n---\n\n## Updating existing records\n\nWhen a payload matches a contact or company that already exists, `INTAKE_MERGE_POLICY`\ndecides what happens to fields that already hold a value.\n\n| Policy | Behaviour |\n|---|---|\n| `PRESERVE` *(default)* | Fills fields that are empty, leaves everything else as it is |\n| `NEWEST_WINS` | The incoming payload overwrites — how versions before 0.4.0 behaved |\n\nUnder both policies a **blank incoming value never overwrites anything**. An absent\nfield means the sender had nothing to say about it, not that it should be cleared.\n\n`PRESERVE` is the default because the alternative loses data with no record of what\nwas there. A returning enquiry typed in lowercase should not replace a name a\nsalesperson corrected by hand, and nothing in a CRM undoes a field a webhook\noverwrote at 3am.\n\nOverride it per source with the source's `mergePolicy`, or per field with a rule's\n`mergeStrategy` — useful for genuinely volatile attributes:\n\n| inputPattern | canonicalName | mergeStrategy |\n|---|---|---|\n| `lead_score` | `extLeadScore` | `NEWEST_WINS` |\n\nThe response body reports what the policy did, per object and per field, under\n`mergeDecisions`.\n\n**Upgrading from 0.3.0 and want the old behaviour?** Set `INTAKE_MERGE_POLICY=NEWEST_WINS`.\n\n> **If a source exists to refresh data, `PRESERVE` will stop it refreshing.**\n> A pipeline that re-scans a business every week and sends back an updated rating,\n> review count or score writes those values once and then never again, because\n> under `PRESERVE` the field already holds a value. This is the one case where the\n> new default is the wrong one. Fix it at whichever scope fits:\n>\n> - the whole source is a refresher → set its `mergePolicy` to `NEWEST_WINS`\n> - only some fields change → give those rules `mergeStrategy: NEWEST_WINS`\n> - every source is a refresher → set `INTAKE_MERGE_POLICY=NEWEST_WINS`\n>\n> Check `mergeDecisions` in the response, or the `Kept the existing …` warnings on\n> the log, to see whether this is happening to you.\n\n---\n\n## Not sending the same lead twice\n\nSend an `Idempotency-Key` header (or an `idempotencyKey` field in the body) and a\nrepeat of that key resolves to the record made the first time, instead of creating a\nsecond one:\n\n```bash\ncurl -X POST https://your-crm.com/s/intake/contact-form \\\n  -H \"Content-Type: application/json\" \\\n  -H \"Idempotency-Key: submission-8f21c9\" \\\n  -d '{\"email\":\"jane@acme.com\"}'\n```\n\nUnlike the content-hash deduplication — which only looks back\n`INTAKE_DEDUP_WINDOW_MINUTES` — an idempotency key has **no time limit**. A\ndouble-tapped submit button, a client retrying after a timeout and a queue\nredelivering an hour later all resolve to the same record.\n\nA key whose only previous use was quarantined or discarded is treated as unused, so\na released payload is not blocked by its own earlier attempt.\n\n---\n\n## Spam quarantine\n\nOff by default. Two mechanisms, and they work independently.\n\n**Honeypot** — set `INTAKE_HONEYPOT_FIELD` (or a source's `honeypotField`) to the\nname of a form field hidden from people by CSS. Any payload arriving with it filled\nwas filled by a script, and is quarantined immediately. No false positives, so this\nworks whether or not scoring is enabled.\n\n**Scoring** — set `INTAKE_SPAM_FILTER_ENABLED=true`. Each signal is worth points\nrather than a verdict: a URL in a name field, a disposable or undeliverable email\ndomain, a link blast in the message, one long string pasted into every box, a\nplaceholder phone number. A payload is held when the total reaches\n`INTAKE_SPAM_SCORE_THRESHOLD` (default `5`), so no single signal is enough on its own\n— a genuine lead writing from a throwaway address still gets through.\n\nSignals that would score *people* rather than behaviour are deliberately absent.\nNon-Latin characters in a name and industry words like \"SEO\" carry no penalty.\n\nA quarantined payload creates **no Person, Company, Opportunity or Note**. It is\nrecorded as an `IntakeLog` with status `QUARANTINED`, its score and its reasons, and\nthe webhook answers `202` — telling a bot which attempts were caught only teaches it\nwhat to change, and a real person should not see a failure on a form that in fact\nwent through.\n\n```bash\n# What is being held, and why\ncurl https://your-crm.com/s/intake/quarantine -H \"Authorization: Bearer $KEY\"\n\n# Let one through — the filter is overruled, the score is still recorded\ncurl -X POST https://your-crm.com/s/intake/quarantine/$LOG_ID/release -H \"Authorization: Bearer $KEY\"\n\n# Mark one as junk; add {\"purgePayload\":true} to drop the stored body\ncurl -X POST https://your-crm.com/s/intake/quarantine/$LOG_ID/discard -H \"Authorization: Bearer $KEY\"\n```\n\nTurn scoring on only after watching the `spamScore` on a few days of real logs.\n\n---\n\n## Replay: applying a mapping you added too late\n\nEvery payload is stored on its log, so a rule written after the fact can be applied\nto everything already received.\n\n```bash\n# One log, through the rules as they are now\ncurl -X POST https://your-crm.com/s/intake/logs/$LOG_ID/replay -H \"Authorization: Bearer $KEY\"\n\n# A batch — see what would be touched first\ncurl -X POST https://your-crm.com/s/intake/replay \\\n  -H \"Authorization: Bearer $KEY\" -H \"Content-Type: application/json\" \\\n  -d '{\"sourceSlug\":\"contact-form\",\"since\":\"2026-08-01T00:00:00Z\",\"dryRun\":true}'\n\n# Then run it\ncurl -X POST https://your-crm.com/s/intake/replay \\\n  -H \"Authorization: Bearer $KEY\" -H \"Content-Type: application/json\" \\\n  -d '{\"sourceSlug\":\"contact-form\",\"since\":\"2026-08-01T00:00:00Z\",\"limit\":50}'\n```\n\nReplay accepts logs that already **succeeded** — that is the point, since the\ningestion worked and only the mapping was missing. Retry is the narrower operation\nand still refuses a successful log.\n\nReplays run one at a time and are capped by `INTAKE_REPLAY_MAX_BATCH`, because each\none writes to the CRM. Each new log records `replayOfLogId`, so a re-mapped record\ntraces back to the payload it came from.\n\n### What is stored, and what is not\n\n`INTAKE_RAW_PAYLOAD_RETENTION=FULL` (the default) keeps each payload as sent, which\nis what retry and replay run from. `NONE` keeps nothing and disables both.\n\nUnder either setting, **credentials are never stored** — keys containing `password`,\n`token`, `secret`, `apikey`, `authorization`, `cvv`, `card`, `ssn` and similar are\nreplaced with `[redacted]` before the payload is written.\n\nEverything else the sender submitted **is** kept, including names, emails and phone\nnumbers. It lives on the `IntakeLog` object under your workspace's own access\ncontrol and is readable by anyone who can read that object. Payloads over\n`INTAKE_RAW_PAYLOAD_MAX_BYTES` are ingested normally but not stored — a truncated\npayload cannot be parsed, so it is dropped rather than half-kept, and the log says so.\n\n---\n\n## Knowing when a source goes quiet\n\nThe failure nobody notices is the one that produces no error: a form that breaks in\nFebruary and is found in August, with nothing but absent leads as evidence.\n\nGive a source an `expectedCadenceHours` and it becomes monitored. Sources without\none are never flagged — silence is only a fault where traffic was expected.\n\n```bash\n# Evaluate every source; run this on whatever timer you already have\ncurl -X POST https://your-crm.com/s/intake/sources/check-silence -H \"Authorization: Bearer $KEY\"\n```\n\nThe check records `healthStatus` (`HEALTHY`, `SILENT`, `NEVER_RECEIVED`) and\n`silentSince` on each source, and posts once to the source's `alertWebhookUrl` on\nthe transition into silence — once, not on every check. The body carries a `text`\nkey, so Slack, Discord and Teams incoming webhook URLs work unchanged.\n\n`GET /s/intake/health` also reports silent sources. It still returns `200` and the\nsame `status` and `timestamp` keys it always did, so existing monitors are\nunaffected. Point a monitor at `/s/intake/health?strict=true` to get a `503` when a\nsource has fallen silent.\n\n---\n\n## Asking the app what it accepts\n\n```bash\ncurl https://your-crm.com/s/intake/contract -H \"Authorization: Bearer $KEY\"\n```\n\nOne call returns every endpoint, the built-in field map grouped by destination, the\ncustom fields that currently exist on each object, the active rules, every\nregistered source and the settings in force — so an integrator or an agent can learn\nthe contract without reading source or introspecting Twenty's metadata API.\n\nSigning secrets never appear; a source reports only whether it requires a signature.\n\n---\n\n## Webhook security\n\nSign requests with `HMAC-SHA256` using the source's secret:\n\n```bash\nSECRET=\"your-signing-secret\"\nPAYLOAD='{\"email\":\"jane@co.com\"}'\nSIGNATURE=$(echo -n \"$PAYLOAD\" | openssl dgst -sha256 -hmac \"$SECRET\" | awk '{print $2}')\n\ncurl -X POST https://your-crm.com/s/intake/contact-form \\\n  -H \"Content-Type: application/json\" \\\n  -H \"X-Webhook-Signature: sha256=$SIGNATURE\" \\\n  -d \"$PAYLOAD\"\n```\n\nSources without a secret accept unsigned requests — useful for internal tools. Set `INTAKE_REQUIRE_HMAC=true` to enforce signatures globally.\n\n---\n\n## Endpoints\n\n| Method | Path | Auth | Description |\n|---|---|---|---|\n| `POST` | `/s/intake/:slug` | HMAC or open | Ingest a payload |\n| `POST` | `/s/intake/:slug/test` | None | Dry-run — structured diff, writes nothing |\n| `GET` | `/s/intake/health` | None | Health check, plus silent sources |\n| `GET` | `/s/intake/contract` | API key | What the app accepts and how it is configured |\n| `POST` | `/s/intake/sources/register` | API key | Register a new source |\n| `POST` | `/s/intake/sources/check-silence` | API key | Check every source against its cadence |\n| `POST` | `/s/intake/logs/:logId/retry` | API key | Retry a **failed** ingestion |\n| `POST` | `/s/intake/logs/:logId/replay` | API key | Re-run **any** stored payload through current rules |\n| `POST` | `/s/intake/replay` | API key | Bulk replay a selection of logs |\n| `GET` | `/s/intake/quarantine` | API key | List held payloads and why |\n| `POST` | `/s/intake/quarantine/:logId/release` | API key | Ingest a held payload |\n| `POST` | `/s/intake/quarantine/:logId/discard` | API key | Mark a held payload as junk |\n\n### Response codes\n\n| Code | Meaning |\n|---|---|\n| `200` | Ingested, or a duplicate resolved to the original record |\n| `202` | Held for review by the spam filter — nothing was created |\n| `401` | Signature missing or invalid |\n| `404` | No source with that slug |\n| `423` | Source is paused |\n\n---\n\n## Retry failed ingestions\n\nEvery ingestion is logged in `IntakeLog`. Failed logs can be retried from the record's detail page in Twenty, or via API:\n\n```bash\ncurl -X POST https://your-crm.com/s/intake/logs/LOG_ID/retry \\\n  -H \"Authorization: Bearer YOUR_API_KEY\"\n```\n\n---\n\n## Development\n\n```bash\ngit clone https://github.com/FranciscoContreras/twenty-app-intake\ncd twenty-app-intake\nyarn install\n\n# Run unit tests\nyarn test\n\n# Connect to your Twenty instance\nyarn twenty remote add --api-url https://your-crm.com --api-key YOUR_KEY --as production\n\n# Sync in watch mode\nyarn twenty dev\n\n# One-shot sync\nyarn twenty dev --once\n```\n\n---\n\n## vs. the alternatives\n\n| | Intake | Zapier/Make | Hookdeck | Custom webhook |\n|---|---|---|---|---|\n| Zero config | ✅ | ❌ Manual mapping | ❌ Write ingestion logic | ❌ Build everything |\n| Auto schema extension | ✅ | ❌ New fields break flows | ❌ | ❌ |\n| Native Twenty objects | ✅ | ❌ | ❌ | ❌ |\n| Deduplication | ✅ | Partial | ❌ | Roll your own |\n| Audit log | ✅ | ❌ | ✅ | ❌ |\n| Self-hosted | ✅ | ❌ | Paid | ✅ |\n| Open source | ✅ MIT | ❌ | ❌ | ✅ |\n\n---\n\n## License\n\nMIT — built by [Machina](https://wearemachina.com) · [FranciscoContreras](https://github.com/FranciscoContreras)\n",
+    "aboutDescription": "<div align=\"center\">\n  <img src=\"./public/logo.svg\" width=\"80\" height=\"80\" alt=\"Intake logo\" />\n  <h1>Intake</h1>\n  <p><strong>The missing ingestion layer for Twenty CRM.</strong><br/>\n  Wire any form, webhook, or data source to Twenty. Leads land clean — every time.</p>\n\n  [![npm version](https://img.shields.io/npm/v/twenty-app-intake?color=0F172A&labelColor=334155&label=npm)](https://www.npmjs.com/package/twenty-app-intake)\n  [![Twenty](https://img.shields.io/badge/Twenty-%3E%3D2.26.0-0F172A?labelColor=334155)](https://twenty.com)\n  [![Tests](https://img.shields.io/badge/tests-68%20passing-22c55e?labelColor=334155)](https://github.com/FranciscoContreras/twenty-app-intake/actions)\n  [![License](https://img.shields.io/badge/license-MIT-0F172A?labelColor=334155)](./LICENSE)\n  [![Website](https://img.shields.io/badge/website-wearemachina.com-0F172A?labelColor=334155)](https://wearemachina.com)\n\n  <sub>Built by <a href=\"https://wearemachina.com\"><strong>Machina</strong></a></sub>\n</div>\n\n---\n\n## The problem\n\nYour contact forms, pipeline scrapers, and partner APIs each have their own field names. `phone_number` here, `phoneNumber` there, `tel` somewhere else. Half the time a new field appears and breaks your Zap. The other half, someone enters a duplicate that your team has to clean manually.\n\nIntake handles all of it automatically.\n\n## What it does\n\nSend any JSON payload to Intake's webhook. It figures out the rest.\n\n```bash\ncurl -X POST https://your-crm.com/s/intake/getting-started \\\n  -H \"Content-Type: application/json\" \\\n  -d '{\n    \"first_name\": \"Jane\",\n    \"last_name\":  \"Doe\",\n    \"email\":      \"jane@acme.com\",\n    \"phone_number\": \"415-555-0199\",\n    \"company\":    \"Acme Inc\",\n    \"message\":    \"Need a new website by Q3.\",\n    \"utm_source\": \"google\",\n    \"budget\":     \"25000\"\n  }'\n```\n\n**What Twenty gets:**\n- ✅ Person record — Jane Doe, jane@acme.com, +1 415 555 0199\n- ✅ Company record — Acme Inc (linked to Jane)\n- ✅ Opportunity — \"Getting Started — Jane Doe\", stage: NEW\n- ✅ Note — message + UTM source, formatted and attached\n- ✅ Custom field `extBudget` auto-created on Person (first time only)\n\nNo Zaps. No middleware. No broken automations when your form adds a field.\n\n---\n\n## How it works\n\n```\nAny JSON payload\n      │\n      ▼\n① Normalize    phone_number → phone, emailAddress → email, firstName + lastName → name\n      │\n      ▼\n② Classify     short values → CRM fields │ prose / UTMs → note\n      │\n      ▼\n③ Extend       unknown fields → auto-create ext custom fields on Person, Company or Opportunity\n      │\n      ▼\n④ Deduplicate  match by email (Person) or domain (Company) before creating anything\n      │\n      ▼\n⑤ Ingest       Person + Company + Opportunity + Note — one webhook, the full chain\n      │\n      ▼\n⑥ Log          every ingestion recorded in IntakeLog with status, timing, field counts\n```\n\n---\n\n## Get started\n\n### 1. Install\n\nFrom the Twenty marketplace in **Settings → Applications**, search for **Intake** and install.\n\nOn fresh install, Intake automatically creates a \"Getting Started\" source with a ready-to-use webhook URL.\n\n### 2. Register a source\n\n```bash\ncurl -X POST https://your-crm.com/s/intake/sources/register \\\n  -H \"Authorization: Bearer YOUR_API_KEY\" \\\n  -H \"Content-Type: application/json\" \\\n  -d '{\n    \"name\": \"Contact Form\",\n    \"slug\": \"contact-form\",\n    \"targetObject\": \"AUTO\"\n  }'\n```\n\n```json\n{\n  \"webhookUrl\": \"https://your-crm.com/s/intake/contact-form\",\n  \"secret\": \"wh_live_abc123...\"\n}\n```\n\n### 3. Test without writing anything\n\n```bash\ncurl -X POST https://your-crm.com/s/intake/contact-form/test \\\n  -H \"Content-Type: application/json\" \\\n  -d '{\"first_name\":\"Jane\",\"email\":\"jane@co.com\",\"budget\":\"15000\"}'\n```\n\nReturns a structured diff of what *would* happen, without touching the CRM: per object\nwhether it would be **created or updated**, which existing record it matched and on\nwhat, what each field would do to the value already there, and which fields do not\nexist yet and would be added to the schema. Plus the spam score the payload would get.\n\n```jsonc\n{\n  \"dryRun\": true,\n  \"diff\": {\n    \"objects\": [{\n      \"object\": \"person\",\n      \"operation\": \"update\",\n      \"recordId\": \"8f21…\",\n      \"matchedBy\": { \"field\": \"emails.primaryEmail\", \"value\": \"jane@co.com\" },\n      \"fields\": [\n        { \"name\": \"name\", \"status\": \"preserved\", \"existing\": {…}, \"incoming\": {…} },\n        { \"name\": \"phones\", \"status\": \"fill-empty\", \"incoming\": {…} },\n        { \"name\": \"extBudget\", \"status\": \"create\", \"fieldWouldBeCreated\": true }\n      ],\n      \"fieldsToCreate\": [{ \"name\": \"extBudget\", \"type\": \"NUMBER\" }]\n    }]\n  }\n}\n```\n\nBecause it is machine-readable, this is the gate to put in front of live traffic —\nassert on it in a deployment check rather than reading it by eye.\n\n---\n\n## Payload formats\n\nIntake accepts any valid JSON. No required fields.\n\n**Flat (contact form):**\n```json\n{\n  \"first_name\": \"Jane\",\n  \"email\": \"jane@acme.com\",\n  \"company\": \"Acme\",\n  \"message\": \"Looking for a full rebrand.\",\n  \"utm_source\": \"google\"\n}\n```\n\n**Structured (pipeline app):**\n```json\n{\n  \"company\": {\n    \"name\": \"Acme Plumbing\",\n    \"domainName\": { \"primaryLinkUrl\": \"https://acmeplumbing.com\" },\n    \"address\": { \"addressCity\": \"San Jose\", \"addressState\": \"CA\" }\n  },\n  \"person\": {\n    \"name\": { \"firstName\": \"John\", \"lastName\": \"Smith\" },\n    \"emails\": { \"primaryEmail\": \"john@acmeplumbing.com\" }\n  },\n  \"google_rating\": 4.7,\n  \"review_count\": 143,\n  \"analysis\": \"Strong reviews, outdated website.\"\n}\n```\n\n**Arbitrary nested:**\n```json\n{\n  \"submitted_by\": { \"full_name\": \"Alex Thompson\", \"contact_email\": \"alex@co.com\" },\n  \"project\": { \"type\": \"SaaS Dashboard\", \"budget\": \"15k\" },\n  \"referrer\": \"behance\"\n}\n```\n\n---\n\n## Built-in field normalization\n\n100+ mappings ship by default. Some highlights:\n\n| Incoming key | Twenty field |\n|---|---|\n| `phone`, `phone_number`, `phoneNumber`, `tel`, `mobile`, `cell` | `phones.primaryPhoneNumber` |\n| `email`, `email_address`, `contact_email` | `emails.primaryEmail` |\n| `first_name`, `firstName`, `fname` | `name.firstName` |\n| `last_name`, `lastName`, `surname` | `name.lastName` |\n| `name`, `full_name`, `fullName` | `name` (auto-split) |\n| `company`, `company_name`, `business`, `organization` | Company record |\n| `website`, `url`, `domain`, `homepage` | `domainName.primaryLinkUrl` |\n| `utm_source/medium/campaign/content/term` | Note (always) |\n| `message`, `description`, `notes`, `comments`, `analysis` | Note (always) |\n\nKey matching ignores case and separator style, so `Email`, `email`, `E-Mail`, `EMAIL`\nand `emailAddress` all reach the same mapping. Nested payloads are flattened first —\n`{\"contact\": {\"first_name\": \"Jane\"}}` becomes `contactFirstName`.\n\n> **Fixed in 0.5.0.** A key that merely *started* with a capital — `Email`, `Phone`,\n> `First Name`, the default labels most form builders send — missed the built-in map\n> entirely and fell through to passthrough, producing a person with an `extEmail`\n> column and no email address on the record. Because deduplication runs on the email,\n> every later submission from that person created another copy. If a source of yours\n> sends capitalised keys, look for `extEmail`, `extPhone` and `extFirstName` columns\n> left behind by earlier runs.\n\nUnknown fields get an `ext_` prefix and are created as custom fields the first time they appear.\n\n---\n\n## Custom field rules\n\nAdd `IntakeFieldRule` records to extend or override the built-in map for a specific source or globally:\n\n| Field | Description |\n|---|---|\n| `inputPattern` | Exact key name or JavaScript regex — see [How a pattern is matched](#how-a-pattern-is-matched) |\n| `canonicalName` | Target field in Twenty. An `ext`-prefixed name (`extBudget`) is created automatically; any other name must already exist on the target object |\n| `fieldType` | `TEXT`, `NUMBER`, `BOOLEAN`, `DATE`, `DATE_TIME`, `CURRENCY`, `LINKS`, `EMAILS`, `PHONES`, `RICH_TEXT`, `RAW_JSON`, `NOTE`, or `SKIP` |\n| `targetObject` | `AUTO` (default), `PERSON`, `COMPANY`, or `OPPORTUNITY` |\n| `mergeStrategy` | `INHERIT` (default), `PRESERVE`, or `NEWEST_WINS` — see [Updating existing records](#updating-existing-records) |\n| `priority` | Higher = checked first (0–100) |\n\nRules with no source linked apply globally across all sources.\n\n### Which mapping wins\n\nEvery incoming key is resolved in this order:\n\n1. **Your rules**, highest `priority` first\n2. **The built-in map**\n3. **Passthrough** — an `ext`-prefixed custom field with an auto-detected type\n\nA rule beats the built-in map. That is what makes a rule worth configuring: it is\nhow `utm_source` becomes a real field instead of a line in the note, and how a\n`website` goes somewhere other than the company's domain.\n\n> **Changed in 0.5.0.** Before 0.5.0 the built-in map was consulted *first*, so a\n> rule naming any of the 100+ built-in keys was silently ignored — the opposite of\n> what this page has always described. If you wrote a rule against a built-in key\n> and worked around it doing nothing, that workaround is now live. Check any rule\n> matching `utm_*`, `website`, `url`, `domain`, `message`, `notes`, `city`, `state`\n> or `country` before upgrading.\n\n**One exception.** A rule cannot take a contact's `name`, `email` or `phone` away\nfrom the contact — it may restate the mapping and set the type, target and merge\nstrategy, but it cannot send the value to a different field, to the note, or to the\nbin. A person with no email cannot be found again, so the next submission from the\nsame address would create a duplicate, and the one after that another. When a rule\nis turned away for this reason the ingest log says so by name.\n\nTo put a second address or a company switchboard somewhere of your own, match a key\nthe built-in map does not already own — `company_email`, `alt_phone`, `direct_line`.\nThose behave like any other key.\n\n### How a pattern is matched\n\n`inputPattern` is tried as an exact key name first, then as a JavaScript regex\n(case-insensitive). Both are tested against **both spellings of the key**: the\nliteral key as it arrived, and its `snake_case` form.\n\nNested payloads are flattened to camelCase before rules run, so `{\"lead\": {\"id\": 1}}`\narrives as `leadId`. Writing `^lead_id$` or `^leadId$` therefore both work, and so\ndoes the bare string `lead_id`.\n\n> **Fixed in 0.5.0.** Patterns were previously tested against the camelCased key\n> only, so `^lead_id$` never matched anything while the bare string `lead_id` matched\n> fine. Patterns without underscores — `budget`, `amount`, `gclid` — were unaffected,\n> which made the failure look arbitrary. A regex that was silently dead may now start\n> matching; check any pattern you wrote with an underscore in it.\n\nA pattern that is not valid regex still works as an exact key match rather than\nbeing discarded.\n\n### Writing to the Opportunity\n\nDeal attributes — the service someone asked for, the budget they stated, your own\nlead id — belong on the Opportunity, not the contact. Two ways to put them there:\n\n**A prefix, no configuration.** Any incoming key beginning `opportunity_`, `opp_`\nor `deal_` is routed to the deal, and the prefix is stripped before the field is\nnamed — `opportunity_budget` becomes `extBudget` on the Opportunity.\n\n```jsonc\n{ \"email\": \"jane@acme.com\", \"opportunity_budget\": \"25000\", \"opportunity_service\": \"SEO\" }\n```\n\n**A rule, for keys you cannot rename.** Set `targetObject: OPPORTUNITY` on the rule\nand point `canonicalName` at the field you want written:\n\n| inputPattern | canonicalName | targetObject | fieldType |\n|---|---|---|---|\n| `service` | `machinaService` | `OPPORTUNITY` | `TEXT` |\n| `budget` | `amount` | `OPPORTUNITY` | `CURRENCY` |\n\n`amount` and `closeDate` are standard Opportunity fields and are set as the deal is\ncreated; `amount` accepts a bare number or a written figure (`\"$25,000/mo\"`) and is\nconverted to Twenty's currency micros. Everything else is written as a custom field\nin a follow-up call, so a rejected field never costs you the Opportunity itself.\n\nA field routed to the Opportunity by a source that does not create one falls back to\nthe primary record, with a warning on the log.\n\n### Companies from email domains\n\n**Intake never reads an employer out of an email address.** A company is created\nonly when the payload actually names one (`company`, `business`, `organization`) or\ngives a domain of its own (`website`, `domain`, `url`). A lead from\n`jane@gmail.com` with no company field creates a person and no company at all.\n\nThis is deliberate. Most small-business enquiries arrive from a consumer mailbox, so\na webhook that inferred companies from email domains would fill the Companies table\nwith mail hosts — a company called \"gmail.com\" with forty unrelated people filed\nunder it. If a mail provider arrives in a *website* field, Intake leaves it off the\ncompany record and says so in the ingest log rather than storing it.\n\n> **Twenty itself does infer companies this way, and it is on by default.** Every new\n> workspace is seeded with a workflow called **\"Create company when adding a new\n> person\"**, which fires on any person whose `emails` field is written — including\n> people created through the REST and GraphQL APIs, and therefore including everything\n> Intake writes. It extracts the domain from the person's email, creates a company for\n> it if none matches, and then **updates the person's `companyId` to point at it** —\n> overwriting the company Intake had already linked them to.\n>\n> The symptom is one lead producing two companies: the correct one on the Opportunity,\n> and a domain-named one on the Person. Twenty's workflow skips a list of common\n> personal domains (`gmail.com`, `yahoo.com`, `outlook.com`, `icloud.com` and similar),\n> so it shows up on leads from business addresses.\n>\n> Nothing an app can send suppresses it — passing an explicit `companyId` does not.\n> If you want Intake's company linkage to stand, open **Settings → Workflows**, find\n> \"Create company when adding a new person\", and deactivate it.\n\n### Fields that cannot be written\n\nA rule pointing at a field that does not exist — and is not `ext`-prefixed, so cannot\nbe auto-created — has its value routed to the note, with a warning naming the field.\nIt is not counted as matched. Create the field in Twenty first, or rename the rule's\n`canonicalName` to use an `ext` prefix.\n\n---\n\n## Source configuration\n\nEach `IntakeSource` record controls:\n\n| Field | Default | Description |\n|---|---|---|\n| `targetObject` | `AUTO` | `PERSON`, `COMPANY`, or auto-detect |\n| `webhookSecret` | — | HMAC-SHA256 signing secret |\n| `createOpportunity` | `true` | Auto-create Opportunity per ingestion |\n| `opportunityNameTemplate` | `{{source}} — {{firstName}} {{lastName}}` | Supports `{{source}}`, `{{firstName}}`, `{{lastName}}`, `{{email}}`, `{{company}}` |\n| `status` | `ACTIVE` | Pause a source without deleting it |\n| `mergePolicy` | — | Overrides `INTAKE_MERGE_POLICY` for this source |\n| `honeypotField` | — | Overrides `INTAKE_HONEYPOT_FIELD` for this source |\n| `expectedCadenceHours` | — | How long this source may go quiet before it counts as silent |\n| `alertWebhookUrl` | — | Posted to once when this source falls silent |\n\n---\n\n## Workspace settings\n\nConfigurable from **Settings → Applications → Intake → Custom**:\n\n| Setting | Default | Description |\n|---|---|---|\n| `INTAKE_APP_LABEL` | `Intake` | Name used in note titles and opportunity names |\n| `INTAKE_DEFAULT_OPP_STAGE` | `NEW` | Stage for auto-created Opportunities |\n| `INTAKE_FIELD_CREATION_ENABLED` | `true` | Toggle auto-schema extension |\n| `INTAKE_MAX_EXT_FIELDS` | `50` | Cap on custom fields per object |\n| `INTAKE_DEDUP_WINDOW_MINUTES` | `5` | Duplicate suppression window |\n| `INTAKE_REQUIRE_HMAC` | `false` | Enforce signed webhooks globally |\n| `INTAKE_MERGE_POLICY` | `PRESERVE` | What an update does to a field that already has a value |\n| `INTAKE_SPAM_FILTER_ENABLED` | `false` | Score payloads and quarantine at the threshold |\n| `INTAKE_SPAM_SCORE_THRESHOLD` | `5` | Score at which a payload is held |\n| `INTAKE_HONEYPOT_FIELD` | — | Name of a hidden form field that quarantines when filled |\n| `INTAKE_RAW_PAYLOAD_RETENTION` | `FULL` | `FULL` keeps payloads for replay; `NONE` keeps none |\n| `INTAKE_RAW_PAYLOAD_MAX_BYTES` | `65000` | Largest payload stored for replay |\n| `INTAKE_REPLAY_MAX_BATCH` | `50` | Cap on one bulk replay (hard ceiling 500) |\n\n---\n\n## Updating existing records\n\nWhen a payload matches a contact or company that already exists, `INTAKE_MERGE_POLICY`\ndecides what happens to fields that already hold a value.\n\n| Policy | Behaviour |\n|---|---|\n| `PRESERVE` *(default)* | Fills fields that are empty, leaves everything else as it is |\n| `NEWEST_WINS` | The incoming payload overwrites — how versions before 0.4.0 behaved |\n\nUnder both policies a **blank incoming value never overwrites anything**. An absent\nfield means the sender had nothing to say about it, not that it should be cleared.\n\n`PRESERVE` is the default because the alternative loses data with no record of what\nwas there. A returning enquiry typed in lowercase should not replace a name a\nsalesperson corrected by hand, and nothing in a CRM undoes a field a webhook\noverwrote at 3am.\n\nOverride it per source with the source's `mergePolicy`, or per field with a rule's\n`mergeStrategy` — useful for genuinely volatile attributes:\n\n| inputPattern | canonicalName | mergeStrategy |\n|---|---|---|\n| `lead_score` | `extLeadScore` | `NEWEST_WINS` |\n\nThe response body reports what the policy did, per object and per field, under\n`mergeDecisions`.\n\n**Upgrading from 0.3.0 and want the old behaviour?** Set `INTAKE_MERGE_POLICY=NEWEST_WINS`.\n\n> **If a source exists to refresh data, `PRESERVE` will stop it refreshing.**\n> A pipeline that re-scans a business every week and sends back an updated rating,\n> review count or score writes those values once and then never again, because\n> under `PRESERVE` the field already holds a value. This is the one case where the\n> new default is the wrong one. Fix it at whichever scope fits:\n>\n> - the whole source is a refresher → set its `mergePolicy` to `NEWEST_WINS`\n> - only some fields change → give those rules `mergeStrategy: NEWEST_WINS`\n> - every source is a refresher → set `INTAKE_MERGE_POLICY=NEWEST_WINS`\n>\n> Check `mergeDecisions` in the response, or the `Kept the existing …` warnings on\n> the log, to see whether this is happening to you.\n\n---\n\n## Not sending the same lead twice\n\nSend an `Idempotency-Key` header (or an `idempotencyKey` field in the body) and a\nrepeat of that key resolves to the record made the first time, instead of creating a\nsecond one:\n\n```bash\ncurl -X POST https://your-crm.com/s/intake/contact-form \\\n  -H \"Content-Type: application/json\" \\\n  -H \"Idempotency-Key: submission-8f21c9\" \\\n  -d '{\"email\":\"jane@acme.com\"}'\n```\n\nUnlike the content-hash deduplication — which only looks back\n`INTAKE_DEDUP_WINDOW_MINUTES` — an idempotency key has **no time limit**. A\ndouble-tapped submit button, a client retrying after a timeout and a queue\nredelivering an hour later all resolve to the same record.\n\nA key whose only previous use was quarantined or discarded is treated as unused, so\na released payload is not blocked by its own earlier attempt.\n\n---\n\n## Spam quarantine\n\nOff by default. Two mechanisms, and they work independently.\n\n**Honeypot** — set `INTAKE_HONEYPOT_FIELD` (or a source's `honeypotField`) to the\nname of a form field hidden from people by CSS. Any payload arriving with it filled\nwas filled by a script, and is quarantined immediately. No false positives, so this\nworks whether or not scoring is enabled.\n\n**Scoring** — set `INTAKE_SPAM_FILTER_ENABLED=true`. Each signal is worth points\nrather than a verdict: a URL in a name field, a disposable or undeliverable email\ndomain, a link blast in the message, one long string pasted into every box, a\nplaceholder phone number. A payload is held when the total reaches\n`INTAKE_SPAM_SCORE_THRESHOLD` (default `5`), so no single signal is enough on its own\n— a genuine lead writing from a throwaway address still gets through.\n\nSignals that would score *people* rather than behaviour are deliberately absent.\nNon-Latin characters in a name and industry words like \"SEO\" carry no penalty.\n\nA quarantined payload creates **no Person, Company, Opportunity or Note**. It is\nrecorded as an `IntakeLog` with status `QUARANTINED`, its score and its reasons, and\nthe webhook answers `202` — telling a bot which attempts were caught only teaches it\nwhat to change, and a real person should not see a failure on a form that in fact\nwent through.\n\n```bash\n# What is being held, and why\ncurl https://your-crm.com/s/intake/quarantine -H \"Authorization: Bearer $KEY\"\n\n# Let one through — the filter is overruled, the score is still recorded\ncurl -X POST https://your-crm.com/s/intake/quarantine/$LOG_ID/release -H \"Authorization: Bearer $KEY\"\n\n# Mark one as junk; add {\"purgePayload\":true} to drop the stored body\ncurl -X POST https://your-crm.com/s/intake/quarantine/$LOG_ID/discard -H \"Authorization: Bearer $KEY\"\n```\n\nTurn scoring on only after watching the `spamScore` on a few days of real logs.\n\n---\n\n## Replay: applying a mapping you added too late\n\nEvery payload is stored on its log, so a rule written after the fact can be applied\nto everything already received.\n\n```bash\n# One log, through the rules as they are now\ncurl -X POST https://your-crm.com/s/intake/logs/$LOG_ID/replay -H \"Authorization: Bearer $KEY\"\n\n# A batch — see what would be touched first\ncurl -X POST https://your-crm.com/s/intake/replay \\\n  -H \"Authorization: Bearer $KEY\" -H \"Content-Type: application/json\" \\\n  -d '{\"sourceSlug\":\"contact-form\",\"since\":\"2026-08-01T00:00:00Z\",\"dryRun\":true}'\n\n# Then run it\ncurl -X POST https://your-crm.com/s/intake/replay \\\n  -H \"Authorization: Bearer $KEY\" -H \"Content-Type: application/json\" \\\n  -d '{\"sourceSlug\":\"contact-form\",\"since\":\"2026-08-01T00:00:00Z\",\"limit\":50}'\n```\n\nReplay accepts logs that already **succeeded** — that is the point, since the\ningestion worked and only the mapping was missing. Retry is the narrower operation\nand still refuses a successful log.\n\nReplays run one at a time and are capped by `INTAKE_REPLAY_MAX_BATCH`, because each\none writes to the CRM. Each new log records `replayOfLogId`, so a re-mapped record\ntraces back to the payload it came from.\n\n### What is stored, and what is not\n\n`INTAKE_RAW_PAYLOAD_RETENTION=FULL` (the default) keeps each payload as sent, which\nis what retry and replay run from. `NONE` keeps nothing and disables both.\n\nUnder either setting, **credentials are never stored** — keys containing `password`,\n`token`, `secret`, `apikey`, `authorization`, `cvv`, `card`, `ssn` and similar are\nreplaced with `[redacted]` before the payload is written.\n\nEverything else the sender submitted **is** kept, including names, emails and phone\nnumbers. It lives on the `IntakeLog` object under your workspace's own access\ncontrol and is readable by anyone who can read that object. Payloads over\n`INTAKE_RAW_PAYLOAD_MAX_BYTES` are ingested normally but not stored — a truncated\npayload cannot be parsed, so it is dropped rather than half-kept, and the log says so.\n\n---\n\n## Knowing when a source goes quiet\n\nThe failure nobody notices is the one that produces no error: a form that breaks in\nFebruary and is found in August, with nothing but absent leads as evidence.\n\nGive a source an `expectedCadenceHours` and it becomes monitored. Sources without\none are never flagged — silence is only a fault where traffic was expected.\n\n```bash\n# Evaluate every source; run this on whatever timer you already have\ncurl -X POST https://your-crm.com/s/intake/sources/check-silence -H \"Authorization: Bearer $KEY\"\n```\n\nThe check records `healthStatus` (`HEALTHY`, `SILENT`, `NEVER_RECEIVED`) and\n`silentSince` on each source, and posts once to the source's `alertWebhookUrl` on\nthe transition into silence — once, not on every check. The body carries a `text`\nkey, so Slack, Discord and Teams incoming webhook URLs work unchanged.\n\n`GET /s/intake/health` also reports silent sources. It still returns `200` and the\nsame `status` and `timestamp` keys it always did, so existing monitors are\nunaffected. Point a monitor at `/s/intake/health?strict=true` to get a `503` when a\nsource has fallen silent.\n\n---\n\n## Asking the app what it accepts\n\n```bash\ncurl https://your-crm.com/s/intake/contract -H \"Authorization: Bearer $KEY\"\n```\n\nOne call returns every endpoint, the built-in field map grouped by destination, the\ncustom fields that currently exist on each object, the active rules, every\nregistered source and the settings in force — so an integrator or an agent can learn\nthe contract without reading source or introspecting Twenty's metadata API.\n\nSigning secrets never appear; a source reports only whether it requires a signature.\n\n---\n\n## Webhook security\n\nSign requests with `HMAC-SHA256` using the source's secret:\n\n```bash\nSECRET=\"your-signing-secret\"\nPAYLOAD='{\"email\":\"jane@co.com\"}'\nSIGNATURE=$(echo -n \"$PAYLOAD\" | openssl dgst -sha256 -hmac \"$SECRET\" | awk '{print $2}')\n\ncurl -X POST https://your-crm.com/s/intake/contact-form \\\n  -H \"Content-Type: application/json\" \\\n  -H \"X-Webhook-Signature: sha256=$SIGNATURE\" \\\n  -d \"$PAYLOAD\"\n```\n\nSources without a secret accept unsigned requests — useful for internal tools. Set `INTAKE_REQUIRE_HMAC=true` to enforce signatures globally.\n\n---\n\n## Endpoints\n\n| Method | Path | Auth | Description |\n|---|---|---|---|\n| `POST` | `/s/intake/:slug` | HMAC or open | Ingest a payload |\n| `POST` | `/s/intake/:slug/test` | None | Dry-run — structured diff, writes nothing |\n| `GET` | `/s/intake/health` | None | Health check, plus silent sources |\n| `GET` | `/s/intake/contract` | API key | What the app accepts and how it is configured |\n| `POST` | `/s/intake/sources/register` | API key | Register a new source |\n| `POST` | `/s/intake/sources/check-silence` | API key | Check every source against its cadence |\n| `POST` | `/s/intake/logs/:logId/retry` | API key | Retry a **failed** ingestion |\n| `POST` | `/s/intake/logs/:logId/replay` | API key | Re-run **any** stored payload through current rules |\n| `POST` | `/s/intake/replay` | API key | Bulk replay a selection of logs |\n| `GET` | `/s/intake/quarantine` | API key | List held payloads and why |\n| `POST` | `/s/intake/quarantine/:logId/release` | API key | Ingest a held payload |\n| `POST` | `/s/intake/quarantine/:logId/discard` | API key | Mark a held payload as junk |\n\n### Response codes\n\n| Code | Meaning |\n|---|---|\n| `200` | Ingested, or a duplicate resolved to the original record |\n| `202` | Held for review by the spam filter — nothing was created |\n| `401` | Signature missing or invalid |\n| `404` | No source with that slug |\n| `423` | Source is paused |\n\n---\n\n## Retry failed ingestions\n\nEvery ingestion is logged in `IntakeLog`. Failed logs can be retried from the record's detail page in Twenty, or via API:\n\n```bash\ncurl -X POST https://your-crm.com/s/intake/logs/LOG_ID/retry \\\n  -H \"Authorization: Bearer YOUR_API_KEY\"\n```\n\n---\n\n## Development\n\n```bash\ngit clone https://github.com/FranciscoContreras/twenty-app-intake\ncd twenty-app-intake\nyarn install\n\n# Run unit tests\nyarn test\n\n# Connect to your Twenty instance\nyarn twenty remote add --api-url https://your-crm.com --api-key YOUR_KEY --as production\n\n# Sync in watch mode\nyarn twenty dev\n\n# One-shot sync\nyarn twenty dev --once\n```\n\n---\n\n## vs. the alternatives\n\n| | Intake | Zapier/Make | Hookdeck | Custom webhook |\n|---|---|---|---|---|\n| Zero config | ✅ | ❌ Manual mapping | ❌ Write ingestion logic | ❌ Build everything |\n| Auto schema extension | ✅ | ❌ New fields break flows | ❌ | ❌ |\n| Native Twenty objects | ✅ | ❌ | ❌ | ❌ |\n| Deduplication | ✅ | Partial | ❌ | Roll your own |\n| Audit log | ✅ | ❌ | ✅ | ❌ |\n| Self-hosted | ✅ | ❌ | Paid | ✅ |\n| Open source | ✅ MIT | ❌ | ❌ | ✅ |\n\n---\n\n## License\n\nMIT — built by [Machina](https://wearemachina.com) · [FranciscoContreras](https://github.com/FranciscoContreras)\n",
     "yarnLockChecksum": "df2ded78f38bf57dd8c95ca58fbf7f8a",
-    "packageJsonChecksum": "be8ecf21404725b81adad99b13b3df74",
+    "packageJsonChecksum": "75c31c351895dd0983502a9530d607c3",
     "requiredServerVersionRange": ">=2.26.0",
     "settingsFrontComponent": {
       "universalIdentifier": "4e4cfb3b-508c-413b-a1b2-192a51c31ed4"
@@ -670,6 +670,7 @@
           "name": "fieldType",
           "type": "SELECT",
           "label": "Field Type",
+          "description": "The column type to write, or NOTE / SKIP to route the value instead of storing it. Currency accepts a bare number or a written figure and is stored as a real amount, so it totals in the pipeline.",
           "icon": "IconDatabase",
           "options": [
             {
@@ -693,45 +694,73 @@
               "color": "green",
               "id": "4bcf3c1f-bbc0-5204-9db7-84dc41708e9d"
             },
+            {
+              "value": "DATE",
+              "label": "Date",
+              "position": 3,
+              "color": "orange",
+              "id": "0711cf49-86f8-5a6c-80a8-bc59737745a6"
+            },
             {
               "value": "DATE_TIME",
               "label": "Date/Time",
-              "position": 3,
+              "position": 4,
               "color": "orange",
               "id": "56a4afa6-108a-5128-9b11-c53a8dc81a58"
             },
+            {
+              "value": "CURRENCY",
+              "label": "Currency",
+              "position": 5,
+              "color": "green",
+              "id": "e4709dbe-ef56-542d-aab8-1b6e55b4070d"
+            },
             {
               "value": "LINKS",
               "label": "Link",
-              "position": 4,
+              "position": 6,
               "color": "purple",
               "id": "58a06ba8-2bb1-5475-8dcd-f712c9f8f009"
             },
             {
               "value": "EMAILS",
               "label": "Email",
-              "position": 5,
+              "position": 7,
               "color": "turquoise",
               "id": "f355003c-53a7-59ee-8d79-11674b0a413c"
             },
             {
               "value": "PHONES",
               "label": "Phone",
-              "position": 6,
+              "position": 8,
               "color": "pink",
               "id": "111b696c-988c-5ba5-b0b1-3193b0583f6b"
             },
+            {
+              "value": "RICH_TEXT",
+              "label": "Rich text",
+              "position": 9,
+              "color": "blue",
+              "id": "4c357ccf-bcff-5407-b557-ed7534a284dc"
+            },
+            {
+              "value": "RAW_JSON",
+              "label": "JSON",
+              "position": 10,
+              "color": "gray",
+              "id": "441a914e-725b-50f6-85ce-723342d933d4"
+            },
             {
               "value": "NOTE",
               "label": "Always Note",
-              "position": 7,
+              "position": 11,
               "color": "yellow",
               "id": "985df4ef-bfea-5f63-b85d-9cabc4991c4b"
             },
             {
               "value": "SKIP",
               "label": "Skip",
-              "position": 8,
+              "position": 12,
               "color": "red",
               "id": "d473ce34-345e-561e-88af-a346c3577bcd"
             }
@@ -889,7 +918,7 @@
       "handlerName": "default.config.handler",
       "sourceHandlerPath": "src/logic-functions/contract.ts",
       "builtHandlerPath": "src/logic-functions/contract.mjs",
-      "builtHandlerChecksum": "99283e7d80c9f99a6393365cbf5468bc"
+      "builtHandlerChecksum": "639b438247f62cc87844373c6113c985"
     },
     {
       "universalIdentifier": "3f7a9c21-8d4b-4e6f-a1c2-5b8d0f2e7a4c",
@@ -904,7 +933,7 @@
       "handlerName": "default.config.handler",
       "sourceHandlerPath": "src/logic-functions/test-ingest.ts",
       "builtHandlerPath": "src/logic-functions/test-ingest.mjs",
-      "builtHandlerChecksum": "23560c1d305ffe3900d2c8e81a1f52d3"
+      "builtHandlerChecksum": "4496d3a31069886a026435c95bc95511"
     },
     {
       "universalIdentifier": "4ece4e39-286b-4820-81f4-b7beee71d092",
@@ -919,7 +948,7 @@
       "handlerName": "default.config.handler",
       "sourceHandlerPath": "src/logic-functions/health.ts",
       "builtHandlerPath": "src/logic-functions/health.mjs",
-      "builtHandlerChecksum": "ab596a3b71b91ceff0cab80383519abf"
+      "builtHandlerChecksum": "f79aba8115d40a341410f921dcbb85fc"
     },
     {
       "universalIdentifier": "56d46e18-6cae-4d99-9893-b7d70740c9db",
@@ -949,7 +978,7 @@
       "handlerName": "default.config.handler",
       "sourceHandlerPath": "src/logic-functions/quarantine-release.ts",
       "builtHandlerPath": "src/logic-functions/quarantine-release.mjs",
-      "builtHandlerChecksum": "0b9c0d16070a268a7f90f21462756f91"
+      "builtHandlerChecksum": "77b0149637a40418abe2b1be5fd801da"
     },
     {
       "universalIdentifier": "8323c257-48fe-4bb6-b1dd-166844f575c0",
@@ -970,7 +999,7 @@
       "handlerName": "default.config.handler",
       "sourceHandlerPath": "src/logic-functions/webhook.ts",
       "builtHandlerPath": "src/logic-functions/webhook.mjs",
-      "builtHandlerChecksum": "f12012bc0402a165b50db1f4885f7578"
+      "builtHandlerChecksum": "88e7193ae547a9bb1365d83f2e35b929"
     },
     {
       "universalIdentifier": "8ff98390-7358-4a91-84f3-435f758182a3",
@@ -985,7 +1014,7 @@
       "handlerName": "default.config.handler",
       "sourceHandlerPath": "src/logic-functions/replay-log.ts",
       "builtHandlerPath": "src/logic-functions/replay-log.mjs",
-      "builtHandlerChecksum": "7b869e6c2ed30f2d4a8aedf49efdee25"
+      "builtHandlerChecksum": "b94dd9c1b5933d2fe3d71c068f30146a"
     },
     {
       "universalIdentifier": "90f20396-a69a-4ae4-af20-6be65c565bb5",
@@ -1000,7 +1029,7 @@
       "handlerName": "default.config.handler",
       "sourceHandlerPath": "src/logic-functions/retry.ts",
       "builtHandlerPath": "src/logic-functions/retry.mjs",
-      "builtHandlerChecksum": "e96a784b817bb728a9a46e6566cd9503"
+      "builtHandlerChecksum": "29d0984eec5c4fec19254233a1803385"
     },
     {
       "universalIdentifier": "b82ed4c4-07bc-4095-8ee5-611200626dc0",
@@ -1015,7 +1044,7 @@
       "handlerName": "default.config.handler",
       "sourceHandlerPath": "src/logic-functions/replay-bulk.ts",
       "builtHandlerPath": "src/logic-functions/replay-bulk.mjs",
-      "builtHandlerChecksum": "342c5df9d1a995ec6bcd419b340e37da"
+      "builtHandlerChecksum": "bf8c5c40d87100d7b08a9e0b80638b5f"
     },
     {
       "universalIdentifier": "e836fdd6-fd54-4aa4-ba6d-87d5a02148ef",
@@ -1024,7 +1053,7 @@
       "handlerName": "default.config.handler",
       "sourceHandlerPath": "src/post-install.ts",
       "builtHandlerPath": "src/post-install.mjs",
-      "builtHandlerChecksum": "0a496f144818d5de2427bc66eedb7e25"
+      "builtHandlerChecksum": "3f9ca8becb536e25389e38efc295d3cc"
     },
     {
       "universalIdentifier": "e88cd5f2-ab96-4f89-ac55-78db66b32d66",

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "twenty-app-intake",
-  "version": "0.4.0",
+  "version": "0.5.0",
   "description": "The missing ingestion layer for Twenty CRM. Automatically sync any webhook source — contact forms, pipeline apps, or any platform — with native schema extension, field normalization, and deduplication. Zero manual configuration required.",
   "keywords": [
     "twenty-app",

package/src/logic-functions/contract.mjs

@@ -121,7 +121,7 @@ var IDS = {
 };
 
 // src/constants/version.ts
-var APP_VERSION = "0.4.0";
+var APP_VERSION = "0.5.0";
 
 // src/constants/field-map.ts
 var FIELD_MAP = {