DAF Connect Developer Guide

DAF Connect is a hosted, embeddable onboarding and verification platform for nonprofit-to-enterprise relationships. It handles intake, identity verification, document collection, fraud screening, and reviewer workflows so your team can focus on grantmaking decisions instead of paperwork.

You integrate by dropping a single iframe onto your site. Nonprofits complete an 11-step intake (step 1 collects the legal name, EIN, mailing address, and applicant contact; step 2 verifies the organization); your reviewers receive structured submissions enriched with IRS, OFAC, Stripe, and AI verification data. Onboarding progress — load, step changes, resize, errors and submission — is pushed to your page via the postMessage API so you can react in real time; reviewer decisions after submission (in review, approved, rejected, more info requested, published, withdrawn) reach your backend as server webhooks.

1. Configure your enterprise in the DAF Connect dashboard — branding, required fields, custom questions, allowed domains.
2. Embed the iframe on your site using your public key.
3. Nonprofits complete onboarding — company details and verification, bank account, signer identity, mission, leadership, a security check, financials, your custom questions, documents, then review and submit.
4. Verification pipeline runs automatically — IRS, OFAC, exclusions, web research, document scans, AI review, trust score. First results land in seconds.
5. Your reviewers approve, reject, or request more info from the reviewer dashboard.
6. Email notifications fire to the applicant — a receipt when they submit, then on reviewer decisions (approve / reject / more info / published).
7. Your site receives postMessage callbacks at every step to update UI in real time.

Drop this snippet on the page where you want nonprofits to onboard. The iframe handles every step — Stripe verifications, document uploads, encryption. You just listen for events.

<!-- 1. Container -->
<div id="dafconnect"></div>

<!-- 2. Embed script -->
<script>
  const PUBLIC_KEY = 'YOUR_PUBLIC_KEY'; // From dashboard → Embed
  const iframe = document.createElement('iframe');
  iframe.src = 'https://daf-connect.com/embed/' + PUBLIC_KEY;
  iframe.style.cssText = 'width:100%;height:800px;border:none;border-radius:12px;';
  iframe.allow = 'camera; microphone; clipboard-write';
  document.getElementById('dafconnect').appendChild(iframe);

  // 3. Listen for events
  window.addEventListener('message', (e) => {
    if (!e.data?.type?.startsWith('dafconnect:')) return;
    console.log('[DAF Connect]', e.data.type, e.data);

    if (e.data.type === 'dafconnect:resized') {
      iframe.style.height = (e.data.height + 20) + 'px';
    }
    if (e.data.type === 'dafconnect:complete') {
      // Onboarding finished — refresh your UI
      window.location.reload();
    }
  });
</script>

The iframe is loaded from /embed/:public_key:

<iframe
  src="https://daf-connect.com/embed/pk_abc123xyz"
  style="width:100%; height:800px; border:none; border-radius:12px;"
  allow="camera; microphone; clipboard-write"
  title="Nonprofit onboarding"
></iframe>

Iframe attributes

If you don't want to embed an iframe, link directly to the hosted page at /onboard/:public_key. Useful for emails, QR codes, or shorter integrations.

<a href="https://daf-connect.com/onboard/pk_abc123xyz" target="_blank">
  Start nonprofit application →
</a>

For security, the iframe refuses to render if embedded on a domain that isn't on your enterprise's allowlist. Configure your allowed domains at /app/embed in the dashboard.

{
  "allowed_domains": [
    "yoursite.com",
    "staging.yoursite.com",
    "localhost"
  ]
}

When a request comes from an unauthorized origin, the iframe shows an "Embed not authorized" screen and emits dafconnect:error with code unauthorized_origin.

When embedded, the iframe broadcasts its content height whenever it changes (via ResizeObserver). Resize your iframe to match to avoid double scrollbars. The simplest way is the hosted helper the dashboard's copy-paste snippet already includes — drop it anywhere on the page:

<script src="https://daf-connect.com/embed-resizer.js" async></script>

It finds your DAF Connect iframe (the first one whose src contains /embed/ or /onboard/, even one inserted later inside a modal), listens for the resize event, and sets the iframe height to match — accepting only messages that come from that iframe's own window and origin. Give the script a data-key="YOUR_PUBLIC_KEY" (and optionally data-container="#dafconnect") and it will create the iframe for you. Only the /embed/ route emits resize events — a framed hosted page does not. To handle it yourself:

window.addEventListener('message', (e) => {
  if (e.data?.type === 'dafconnect:resized') {
    const iframe = document.querySelector('#dafconnect iframe');
    iframe.style.height = (e.data.height + 20) + 'px';
  }
});

Common pattern — open the iframe inside a modal triggered by a button:

<button id="open-onboarding">Apply to our giving program</button>

<div id="dafc-modal" style="display:none; position:fixed; inset:0; background:rgba(0,0,0,0.6);
  z-index:9999; align-items:center; justify-content:center;">
  <div style="background:white; width:90%; max-width:700px; height:85vh; border-radius:16px;
    overflow:hidden; position:relative;">
    <button id="dafc-close" style="position:absolute; top:12px; right:12px; z-index:1;
      background:rgba(0,0,0,0.08); border:none; width:32px; height:32px; border-radius:50%;
      cursor:pointer;">✕</button>
    <iframe id="dafc-iframe" style="width:100%; height:100%; border:none;"
      allow="camera; microphone"></iframe>
  </div>
</div>

<script>
  const PUBLIC_KEY = 'YOUR_PUBLIC_KEY'; // From dashboard → Embed
  const modal = document.getElementById('dafc-modal');
  const iframe = document.getElementById('dafc-iframe');
  document.getElementById('open-onboarding').onclick = () => {
    iframe.src = 'https://daf-connect.com/embed/' + PUBLIC_KEY;
    modal.style.display = 'flex';
  };
  document.getElementById('dafc-close').onclick = () => {
    modal.style.display = 'none';
    iframe.src = '';
  };
  window.addEventListener('message', (e) => {
    if (e.data?.type === 'dafconnect:complete') {
      modal.style.display = 'none';
      iframe.src = '';
      alert('Application submitted! Reference: ' + e.data.submissionRef);
    }
  });
</script>

All communication between the iframe and your parent page uses the Window.postMessage API.

All messages include a type field starting with dafconnect:. In production, always verify event.origin before trusting message contents.

All onboarding behaviour is controlled by your Enterprise record, configurable at /app/branding, /app/embed, and /app/settings.

{
  "logo_url": "https://yourcdn.com/logo.svg",
  "primary_color": "#006044",
  "accent_color": "#006990"
}

primary_color sets the top accent border and titles.accent_color sets all CTA buttons and progress indicators.

The wizard always enforces: on step 1 legal_name, a 9-digit ein, applicant_address, applicant_email and applicant_phone; on step 6 two to five leadership contacts (each with name, email, phone and address) with exactly one primary contact who is identity-verified, or who has a government ID uploaded on the manual and GIACT rails; and the verification steps 2 to 4 for the configured rail. Mission (step 5) and Financials (step 8) are optional for applicants. Required documents (step 10) are waived once all three Stripe verifications have passed.

Add organization-specific intake questions on step 9 (Additional questions):

{
  "custom_fields": [
    {
      "key": "service_area",
      "type": "dropdown",
      "label": "Primary service area",
      "required": true,
      "options": ["Education", "Healthcare", "Housing", "Environment", "Other"]
    },
    {
      "key": "annual_beneficiaries",
      "type": "text",
      "label": "Approximate beneficiaries per year",
      "placeholder": "e.g. 5,000",
      "required": false
    },
    {
      "key": "partnership_history",
      "type": "textarea",
      "label": "Tell us about your past corporate partnerships",
      "placeholder": "1-2 paragraphs",
      "required": false
    },
    {
      "key": "previous_grant",
      "type": "yes_no",
      "label": "Have you received a grant from us before?",
      "required": true
    }
  ]
}

Responses are saved on Submission.custom_field_values keyed by the field's key and displayed in the "Custom enterprise questions" section of the reviewer's Organization tab.

Supported field types

The thank-you screen shows your enterprise's success_message text. The iframe does not auto-redirect — handle redirects yourself by listening for the dafconnect:complete event on the parent page:

window.addEventListener('message', (e) => {
  if (e.data?.type === 'dafconnect:complete') {
    window.location.href = '/applied?ref=' + e.data.submissionRef;
  }
});

Enterprise-level feature toggles. stripe_verifications_enabled — along with auto-verification, hide-score, fraud-network name sharing, team MFA policy and data retention — can be changed by an owner or admin on /app/settings (the server rejects saves from other members). The rest, including ai_verification_enabled and hide_daf_branding, are platform-managed — contact your account manager to enable them:

{
  // Verification toggles live on Enterprise.features
  "features": {
    "stripe_verifications_enabled": true,   // Stripe Connect + Identity + Financial Connections
    "ai_verification_enabled": true,         // AI-powered risk recommendation
    "giact_verifications_enabled": false,    // Adds the four GIACT checks (opt-in)
    "charityapi_verifications_enabled": true,  // CharityAPI.org IRS registry corroboration (on unless false)
    "dark_web_monitoring_enabled": true,     // Klaw exposure scan of contacts (on unless false)
    "auto_approve_enabled": false,           // Auto-approve at or above auto_approve_threshold
    "auto_approve_threshold": 80,            // Trust score needed to auto-approve (default 80)
    "verification_cache_days": 30,           // Example: reuse a passed identity check for 30 days
    "share_graph_names": true                // Show your org names to a matched workspace (on unless false)
  },
  // White-label toggle lives on Enterprise.feature_flags
  "feature_flags": {
    "hide_daf_branding": false               // Removes "Secured by DAF Connect" footer
  }
}

The applicant moves through these steps:

Drafts auto-save to localStorage so users can close and resume later from the same browser. Sensitive values — the EIN, bank account and routing numbers, and the signer's ID file — are never written to the draft and must be re-entered on resume: a resumed draft is clamped back to step 1 until the EIN is re-entered, and on the manual and GIACT rails to step 3 or 4 until the bank details or signer ID are re-supplied. A human-verification challenge (Cloudflare Turnstile) is visible for the whole flow and its token is verified server-side at submit.

Steps 2/3/4 (Company, Bank, Identity) operate in one of two modes depending on the stripe_verifications_enabled feature flag:

Sensitive fields are encrypted with AES-256-GCM using a per-enterprise key before being stored. Only authorized reviewers from your enterprise can decrypt.

Encrypted fields

• nonprofit_ein — EIN tax ID
• banking_account_name — Account holder name
• banking_routing — Routing number
• banking_account — Account number
• banking_bank_name — Bank name
• signer_id_file_url — Signer ID document URL
• signer_id_file_name — Signer ID filename

Step 9 collects these documents. The list of types is fixed, but which of them are required is per enterprise: the Embed Manager's "Required documents" toggles ( required_fields) override the defaults below for w9, form_990, audited_financials, insurance and board_list. 501c3_letter has no toggle and keeps its default.

Max file size: 25 MB per file. Validation: Magic-byte MIME validation (file contents must actually match the extension), SHA-256 deduplication, filename sanitization.

Documents are uploaded to private storage during onboarding. Virus scanning via VirusTotal happens after submission in the reviewer panel — reviewers see scan status (Pending / Clean / Infected — or Error when the scanner could not be reached) on each document before opening it; the applicant's own upload list shows the same infected state as Quarantined. Infected files are flagged in the reviewer UI, and a document that has not been scanned is never shown as clean.

The instant the applicant clicks Submit, an asynchronous verification pipeline runs against the submission. First results reach the dashboard in seconds; the research-heavy checks (web research, AI verification) typically complete within a couple of minutes.

The GIACT checks (15–18) are currently pinned to GIACT's sandbox environment while live credentials are being issued — results are labelled Sandbox wherever they appear, are never billed, and deliberately do not move the trust score until the pin is lifted.

The CharityAPI checks (20–23) run for every workspace once the platform's CharityAPI key is in place;charityapi_verifications_enabled: false opts a workspace out. Sandbox workspaces use the CharityAPI test key when one is provided and the live key otherwise. They are route-to-review only — never an auto-reject and never a trust-score input — and a result from a test or emulated key is labelled as such and demoted to a warning before the free-checks gate aggregates.

The pipeline computes a 0–100 trust score (higher = more trustworthy, lower = riskier) and persists it to Submission.score. The score starts at 100, deducts points for each failed, missing, or suspicious signal, and adds a small bonus for a strong signal:

The result is clamped to 0–100. Note: because Stripe document gating makes uploads optional, a fully Stripe-verified applicant with no documents still receives the −10 "no documents uploaded" deduction on this internal score — it does not block submission. The location-vs-address rows are skipped when the applicant is on a VPN — the exit node's location measures nothing, and the VPN is already penalized.

Risk tiers (derived from trust score)

A long-term 0–100 trust score is maintained on each NonProfitOrganization across all submissions. Reviewers see this prominently in the dashboard. Higher = more trusted.

Inputs, adding up to 100: IRS 501(c)(3) status (25), address consistency between IRS and business records (20), contact verification — the share of listed contacts verified, plus a verified contact authorized for banking changes (20), banking verification weighted by how recently the account was verified (20), and IRS data freshness (15). A drift penalty is then subtracted — high −20, medium −10, low −3 — and the result is clamped to 0–100 and bucketed into the same 80/50 tiers as the submission score. Prior submission history is not an input.

Separate from the trust score, a dark web & surface web scan (powered by Klaw) checks the organization's own contact addresses against known breach corpora and returns a 0–100 vulnerability score per contact — higher = more exposed. The organization's headline vulnerability score is the worst-exposed contact, never the average, so one badly breached officer is not diluted by clean colleagues.

It answers a different question than the trust score — not “is this organization legitimate?” but “how much liability is attached to its people?” The same signal also feeds the people-screening contributor to the trust score above. It is exposed on the dark-web-scan VerificationCheck as raw_response.vulnerability_score plus per-contact breach detail (never a leaked credential value). Free on every plan and on by default; applicants can see their own exposure, while the composite trust score stays reviewer-only.

Detects changes since last verification — address moves, banking changes, contact email domain changes, IRS status changes, legal name changes. Each drift gets a severity (low/medium/high).

High-severity drift (e.g. a banking change) makes the payment check return a hold decision for the org until a reviewer clears the drift, under a default rule your risk config can switch off. The hold is a recorded decision: your own payment system is what sends or withholds the grant.

Optional LLM-powered review (enable with features.ai_verification_enabled). Returns:

{
  recommendation: "approve" | "review" | "reject",
  confidence: number,        // 0-100
  reasoning: string,         // Plain-text explanation
  red_flags: string[],       // Specific concerns
  green_flags: string[],     // Specific positives
  document_checks: {         // Fixed per-document-type verdicts, not keyed by document id
    "501c3_letter": "valid" | "invalid" | "missing" | "pending",
    "form_990":     "valid" | "invalid" | "missing" | "pending",
    "w9":           "valid" | "invalid" | "missing" | "pending"
  },
  cross_check_results: {
    address_match: "yes" | "no" | "partial",
    irs_status_current: "yes" | "no" | "unknown",
    ein_format_valid: "yes" | "no"
  },
  model_used: string         // the model that answered, or the fallback
}

Stored as an AIVerificationResult record. When the model omits a field the recommendation defaults to review and the confidence to 50. Outside sandbox mode the pipeline deducts 25 points for a reject recommendation and 10 for a review.

When Stripe is enabled, three live Stripe products are used:

The pipeline's stripe_tax_id step is not a fourth product: when Stripe verifications are enabled and the submission has no tax_id record yet, it reuses a fresh organization-level result if one exists and otherwise opens the same Connect Express account plus a hosted onboarding link.

Results stored on StripeVerification records. Platform admins and enterprise owners or admins — not reviewer-role members — can manually override a verification with a required justification; the record is marked manually_overridden and set to verified, the matching submission flag is set, and the action is audit-logged as stripe_verification_overridden.

Submissions move through these states:

draft
  └─→ submitted (applicant clicks Submit)
        ├─→ in_review (reviewer claims)
        │     ├─→ more_info_requested ──→ submitted (applicant re-submits)
        │     ├─→ rejected (terminal)
        │     └─→ pending_publish (reviewer approves)
        │           └─→ published (terminal — live on enterprise site)
        └─→ withdrawn (applicant cancels)

Reviewer decisions (approve, reject, request more info) are accepted from
submitted, in_review, or more_info_requested — a claim (in_review) is not required first.

Applicant emails go to the nonprofit's contact_email, falling back to the applicant_email captured at the start of onboarding, and are logged in the EmailLog entity. Separately, a nonprofit that has portal accounts gets a plain status-update email (kind status_change) to each active member's login address on every applicant-visible status transition.

Email subject lines and body copy for the confirmation and decision emails are baked into the sendDecisionEmail backend function and personalized with your enterprise name and reviewer-provided reason text. Per-enterprise custom templates are not currently editable from the dashboard — contact your account manager if you need bespoke wording.

Webhooks are server-to-server HTTP callbacks fired the moment a submission's status changes — submitted, in_review, approved, rejected, published, and more. Use them to sync data into your CRM, fire Slack notifications, or kick off internal workflows without polling.

Configure your endpoint at /app/webhooks in the dashboard. Each delivery includes an HMAC-SHA256 signature so you can verify the request really came from DAF Connect.

Go to /app/webhooks and:

1. Enter your endpoint URL (must be https:// — plain http is rejected)
2. Optionally select specific events — leave all unchecked for "everything"
3. Click Register webhook
4. Copy the signing secret immediately — it's only shown once
5. Click Send test ping to verify your endpoint responds with 2xx

You can also call the API directly:

await dafconnect.functions.invoke('registerWebhook', {
  op: 'register',
  enterprise_id: 'ent_abc123',
  url: 'https://yoursite.com/api/dafconnect-webhook',
  events: ['submitted', 'pending_publish', 'rejected'], // [] = subscribe to all
  enabled: true
});
// Response includes webhook_secret ONLY on first registration:
// { ok: true, webhook_url, webhook_secret: 'whsec_...' }

All operations

All events follow the format submission.<status>:

The four partner network events are delivered only when you check them by name — an empty subscription means every submission.* event, never a network event — and only while your enterprise's partner network API is enabled. Checking a network event never changes which submission.* events you receive. Their body has no submission_id; see Partner network API.

Every webhook is a JSON POST to your endpoint with these headers:

{
  "id": "evt_a3f1c8d9-...",
  "event": "submission.pending_publish",
  "created_at": "2026-05-26T15:30:00.000Z",
  "enterprise_id": "ent_abc123",
  "submission_id": "sub_xyz789",
  "livemode": true,
  "data": {
    "submission_ref": "sub_xyz789",
    "status": "pending_publish",
    "previous_status": "in_review",
    "nonprofit_id": "np_abc",
    "nonprofit_name": "Acme Nonprofit Inc",
    "decision_reason": "All verification checks passed. Approved for FY2026.",
    "decided_by": "reviewer@yoursite.com",
    "decided_at": "2026-05-26T15:29:55.000Z",
    "submitted_at": "2026-05-26T10:00:00.000Z",
    "published_at": null,
    "score": 88
  }
}

score is the submission trust score (0–100, higher = more trustworthy) — the same value persisted to Submission.score.

livemode is false on every submission.* and test.ping event from a sandbox, emulation or demo workspace, whose verifications run against fixtures. It is part of the signed body. A production receiver should verify the signature and then reject any event with livemode: false.

Every request includes an X-DAFConnect-Signature header of the form t=<timestamp>,v1=<hex_signature>. To verify:

1. Extract t (timestamp) and v1 (signature)
2. Concatenate `${t}.${rawBody}` (timestamp, dot, raw request body)
3. Compute HMAC-SHA256 of that string using your webhook_secret
4. Compare against v1 in constant time
5. Reject events older than 5 minutes to prevent replay attacks

import crypto from 'node:crypto';

function verifyDafConnectSignature(rawBody, headerValue, secret) {
  if (!headerValue) return false;
  const parts = Object.fromEntries(
    headerValue.split(',').map(p => p.split('='))
  );
  const timestamp = parts.t;
  const signature = parts.v1;
  if (!timestamp || !signature) return false;

  // Replay protection — reject anything older than 5 minutes
  const age = Math.floor(Date.now() / 1000) - parseInt(timestamp);
  if (Math.abs(age) > 300) return false;

  const expected = crypto
    .createHmac('sha256', secret)
    .update(`${timestamp}.${rawBody}`)
    .digest('hex');

  // Constant-time comparison
  return crypto.timingSafeEqual(
    Buffer.from(expected, 'hex'),
    Buffer.from(signature, 'hex')
  );
}

Test endpoint

Use the Send test ping button in /app/webhooks, enabled once an endpoint is registered, to dispatch a test.ping event. The test bypasses your event subscription filter, but not the Paused state: a paused endpoint answers skipped and logs nothing, so resume it first. With no endpoint registered the call returns 400.

Delivery log

Every webhook attempt is logged in the dashboard with HTTP status, response snippet, duration, and any error message. Use this to debug failed deliveries without grepping your server logs.

Local development

The endpoint must be a public https:// URL. As an SSRF safeguard, the validator rejects localhost, loopback, and private or internal hosts (e.g. 127.0.0.1, 10.0.0.0/8, 192.168.0.0/16) — you cannot register a local address directly. Use ngrok or cloudflared to expose your local server over a public HTTPS URL for testing.

Retries

Failed submission.* deliveries are not automatically retried in the current version. The partner network events (organization.*, destination_token.revoked) are: up to 10 attempts within 24 hours, with exponential backoff and full jitter, and the same id on every attempt. Either way your endpoint should be idempotent and tolerant of duplicates — use the id field for deduplication.

Changing the secret

The signing secret is shown exactly once, when it is generated or rotated. To issue a fresh one, use Rotate secret on /app/webhooks (op rotate_secret): the new value is displayed once, the previous key stops verifying immediately, and your URL and event filter are unchanged. The rotation is audit-logged without the secret value.

Optional. When enabled, every finalized submission is held until your backend approves it — the way a card issuer authorizes each payment. DAF Connect POSTs a one-time challenge to your authorization endpoint; your server runs whatever logic it likes (CRM allowlist, budget check, fraud model) and answers with a cryptographic pin. The applicant never sees this step.

Configure it under Per-submission authorization on /app/webhooks (op register_authorization). The endpoint must be a public https:// URL — private and loopback hosts are refused — and it is signed with the same webhook_secret you already hold.

{
  "event": "submission.authorize",
  "challenge": "chal_9f2c...",          // fresh 24-byte nonce on every call
  "timestamp": 1700000000,
  "enterprise_id": "ent_abc123",
  "submission": {
    "id": "sub_xyz789",
    "nonprofit_name": "Acme Nonprofit Inc",
    "nonprofit_id": "np_abc"
  },
  "respond_with": "hmac_sha256_hex(webhook_secret, challenge + '.' + submission.id) as 'authorization'"
}

The request carries X-DAFConnect-Event: submission.authorize and the same X-DAFConnect-Signature header as a webhook delivery — verify it before acting. Respond within 8 seconds.

{
  "approve": true,
  "authorization": "hex HMAC-SHA256 of challenge + '.' + submission.id, keyed with your webhook_secret"
}

{
  "approve": false,
  "reason": "Not on our approved-grantee list"   // relayed to the applicant, up to 300 characters
}

An intake link is a custom, single-use URL that opens your DAF Connect application form exactly once. It stays valid until the applicant submits — then it's consumed, and any later visit to the URL renders a 404. Use it to hand a specific nonprofit a private link (per applicant, no shared public embed) that can't be forwarded or reused after they're done.

The link opens the same onboarding flow as the iframe embed, served from /intake/<token> where <token> is a crypto-random value minted server-side. Links expire automatically 30 days after they're minted if unused.

Two ways to mint a link

Mint from the dashboard (SDK)

The dashboard button uses your signed-in session — no secret needed. Owners and admins only.

const { data } = await dafconnect.functions.invoke('mintIntakeLink', {
  enterprise_id: 'ent_abc123',
  external_ref: 'your-applicant-id-123' // optional
});
// data.url → https://daf-connect.com/intake/ily_live_...
// Drop data.url into an iframe or send it to the applicant.

Mint from your backend (server-to-server)

Have your own server mint a link per applicant with no human in the loop. POST to your branded webhook endpoint, authenticating with the same webhook_secret you manage on the Webhooks page — never expose it in client-side code.

curl -X POST \
  https://daf-connect.com/hooks/v1/intake-links \
  -H 'Content-Type: application/json' \
  -d '{
    "enterprise_id": "ent_abc123",
    "webhook_secret": "YOUR_WEBHOOK_SECRET",
    "external_ref": "your-applicant-id-123"
  }'

{
  "success": true,
  "url": "https://daf-connect.com/intake/ily_live_...",
  "link_id": "il_...",
  "status": "active",
  "expires_at": "2026-06-25T15:30:00.000Z",
  "external_ref": "your-applicant-id-123"
}

A signed, server-to-server API for DAF platforms: find organizations, read DAF Connect's own organization-level verification, dry-run grant eligibility, check electronic-delivery capability, and mint or revoke destination tokens — opaque, single-use references to an organization's verified bank account. A token is not a payment instruction and can never be exchanged for bank digits; DAF Connect does not move money. The API is enabled per enterprise by DAF Connect.

POST https://daf-connect.com/hooks/v1/network
Content-Type: application/json; charset=utf-8
X-DAFConnect-Enterprise: <your enterprise id>
X-DAFConnect-Signature: t=<unix seconds>,v1=<hex HMAC-SHA256(api_secret, t + "." + raw body)>

{"api_version":"2026-10-01","action":"ping","request_id":"<uuid, new per request>","params":{}}

See Modal pattern in the Embedding section above.

Track the onboarding funnel in your analytics platform:

window.addEventListener('message', (e) => {
  if (!e.data?.type?.startsWith('dafconnect:')) return;

  switch (e.data.type) {
    case 'dafconnect:loaded':
      analytics.track('Onboarding Started');
      break;
    case 'dafconnect:stepChanged':
      analytics.track('Onboarding Step Viewed', {
        step: e.data.step,
        total: e.data.totalSteps,
        progress_pct: Math.round((e.data.step / e.data.totalSteps) * 100)
      });
      break;
    case 'dafconnect:submitted':
      analytics.track('Onboarding Submitted', { ref: e.data.submissionRef });
      break;
    case 'dafconnect:complete':
      analytics.track('Onboarding Completed', { ref: e.data.submissionRef });
      break;
    case 'dafconnect:error':
      analytics.track('Onboarding Error', { code: e.data.code, message: e.data.message });
      break;
  }
});

When the applicant is already logged into your site, prefill known fields:

const iframe = document.querySelector('#dafconnect iframe');

window.addEventListener('message', (e) => {
  // Wait for iframe to be ready before sending prefill
  if (e.data?.type === 'dafconnect:loaded') {
    iframe.contentWindow.postMessage({
      type: 'dafconnect:prefill',
      data: {
        legal_name: currentUser.org_name,
        contact_name: currentUser.full_name,
        contact_email: currentUser.email,
        website: currentUser.org_website
      }
    }, '*');
  }
});

A small HTML test harness for verifying your iframe loads, the dafconnect:resized auto-resize handshake works, and what postMessage events the embed is actually emitting. Useful when debugging "why isn't my iframe sizing correctly?" before integrating into your real site.

What you get

• An iframe pointing at your /embed/:public_key URL (editable in the top bar)
• Live width / height controls — type a pixel value or toggle "auto-fit width"
• Status dots showing whether the iframe loaded and whether auto-resize is working
• A black log panel that prints every postMessage event received, including origin & payload — so you can immediately see if the iframe is silent, sending from the wrong origin, or sending the wrong shape

How to use

1. Click Download above to save the file
2. Open the file in your browser — just double-click it (Mac/Linux) or right-click → Open With → your browser (Windows). The page works straight from file:// so no web server is needed.
3. Edit the iframe src input at the top to point at your enterprise's embed URL — e.g. https://daf-connect.com/embed/YOUR_PUBLIC_KEY — then click Reload
4. Watch the dots:
   • iframe load green = the iframe responded
   • auto-resize green = received a dafconnect:resized message with a valid height
5. Scroll through the onboarding flow — every step change, toast, and resize event will appear in the log

All sensitive fields (EIN, banking, signer ID) are encrypted at rest with AES-256-GCM using a unique per-enterprise key. That key is generated automatically the first time your enterprise encrypts anything and lives in a separate, service-role-only secrets vault — it is never stored on the Enterprise record your team can read, and it is never returned by any API, data export included. Each ciphertext includes a fresh 12-byte IV prepended to the encrypted bytes. Decryption is gated twice: row-level security limits it to members of the originating enterprise, and the reviewer's session must hold a verified second factor — platform admins included — or the request returns step_up_required. Every decrypt is audit-logged. Government-ID scans are held in private storage and served only through short-lived signed URLs.

The enforceRetentionPolicies job runs daily and enforces these windows:

The 3-year default can be overridden per enterprise (1 year / 3 years / 7 years / Indefinite). Archived submissions remain inspectable by admins during the 30-day grace period. Owners and admins change the window themselves at /app/settings under Data retention; the value is stored as feature_flags.retention_policy and picked up on the next daily run.

Every entity has RLS enforcing:

• Nonprofit applicants have no read grant on submission rows at all — the nonprofit portal serves a safe subset of their own organization's submissions through server functions, so reviewer-internal fields never reach an applicant
• Enterprise members see only their enterprise's submissions
• Admins see everything (for support purposes)
• Demo tenants get no special read grant — demo rows obey the same tenant rules, and the public demo reads a scrubbed subset through dedicated server functions

Cross-tenant access attempts are blocked at the database level — not just the UI.

The iframe parses document.referrer and window.location.ancestorOrigins to determine the parent's origin. If it isn't on your enterprise's allowed_domains, the iframe refuses to render and emits an error event.

Every data-changing action lands in AuditLog with the actor, IP, user agent, before and after state, and timestamp. Each row is HMAC-sealed and hash-linked to the row before it (seq, prev_hash, entry_hash), so an edited, deleted, or reordered entry is detectable. Rows are written only by backend functions — no tenant member or platform admin can create, alter, or remove one through the API — and a platform-admin verifier (verifyAuditChain) walks the chain and reports the first break. Entries are retained for five years.

Workspace owners and admins can use Settings → Workspace data export to prepare and download JSON. The backend function exportEnterpriseData requires a verified second factor and accepts an active owner/admin membership or a platform enterprises write grant. Every request is rate-limited and audit-logged. op: 'manifest' returns the supported record types, a creation cutoff, exclusions and bounded count estimates; op: 'export' returns a page. Callers pass the same created_before cutoff and follow has_more and next_offset until an empty terminal page. Each next request also carries the last record ID as previous_id; records are ordered by ID and the server verifies the terminal ID against the table's tail. Short pages are not exhaustion, and all positive manifest counts are lower bounds, not export limits. Secrets, account numbers, access links, audit state snapshots and raw provider payloads are withheld. Private file contents, shared nonprofit profiles and platform records are excluded; encrypted values stay encrypted. Collection is not an atomic snapshot or a restorable backup, and redacted audit records cannot verify the original hash chain. The browser stops at 50 MiB or 500 pages and marks interrupted collections incomplete, including the completed record types and error in the file. Contact support for larger exports, private documents or subject-access requests. This function is not part of the public API-key surface.

Every response carries a Strict-Transport-Security header (two years, including subdomains) and a Content-Security-Policy generated from a single source and served as a header. Outbound legs that carry applicant data — webhook deliveries, the per-submission authorization call, and bank-verification relays — are https:// only, refuse redirects, and reject private or loopback hosts.

Public and privileged endpoints call a shared request firewall before doing any work. It inspects payloads for injection, SSRF, and leaked-secret patterns, applies a per-tenant rate ceiling (at most 600 requests per minute, tracked in a durable ten-minute window), and enforces a platform IP allow and deny list in which deny wins. A blocked request returns 403 and is recorded in the audit log with its endpoint and observed IP.

Core data model entities you'll encounter: