How to Integrate Bolt.new with ADP

Before writing any code, it is essential to understand that ADP's API is not publicly accessible. ADP operates an enterprise marketplace model: to call their APIs, you must first complete the ADP Marketplace developer partner application at developers.adp.com. This involves describing your application, agreeing to ADP's commercial terms, and in most cases requiring an existing ADP client to authorize your application to access their ADP data. The certification process typically takes several weeks and involves ADP's partner team reviewing your integration design. ADP's authentication model uses OAuth 2.0 with mutual TLS — meaning your server must present a client certificate alongside standard OAuth credentials. This is more complex than typical API key or Bearer token auth. You'll receive a client certificate (PEM format) and private key from ADP that must be configured on your server. This certificate-based pattern cannot be tested in Bolt's WebContainer development environment — it requires a properly configured server environment, which means deploying to Netlify or Bolt Cloud first. If you're evaluating whether ADP integration is worth pursuing for your project, consider the timeline: expect 4-8 weeks minimum to become a certified ADP Marketplace partner. For early-stage projects, Gusto's developer-friendly REST API, BambooHR's API, or a custom Supabase-based HR system will serve you faster. If you work for an enterprise client actively using ADP, the partner program is the correct path — start at https://developers.adp.com/articles/general/get-started.

1# ADP OAuth 2.0 with mutual TLS (certificate-based auth)
2# Requires: ADP partner account + client certificate from ADP
3# This pattern ONLY works after completing ADP Marketplace partner program
4
5# .env
6ADP_CLIENT_ID=your_adp_client_id
7ADP_CLIENT_SECRET=your_adp_client_secret
8ADP_CERT_PATH=/path/to/adp-client-cert.pem
9ADP_KEY_PATH=/path/to/adp-private-key.pem
10ADP_API_BASE=https://api.adp.com

For most Bolt.new projects needing HR features, building a custom employee management system with Supabase is the fastest and most flexible path. Supabase's PostgREST HTTP API works perfectly in Bolt's WebContainer since it communicates over HTTPS rather than raw TCP. Start by prompting Bolt to create your Supabase schema with the tables you need: employees, departments, time-off requests, and any other HR data your application requires. Open your Supabase project at app.supabase.com and navigate to the SQL Editor. Create your schema there first, then connect it to your Bolt app. The employee table needs at minimum: an ID (UUID), full name, email, department reference, start date, employment status (active/inactive/on-leave), and any compensation data your business needs. Add row-level security (RLS) policies from the start — this ensures managers can only see their department's employees and employees can only view their own profile. In Bolt, use the @supabase/supabase-js SDK to connect — prompt Bolt to add your Supabase URL and anon key from your Supabase project settings. The SDK communicates over HTTPS, so it works both in Bolt's WebContainer preview and after deployment. For sensitive operations like updating salaries or viewing all employee records, create protected API routes that use the Supabase service role key (never the anon key) to bypass RLS — keep the service role key in your server-side environment variables only. This approach gives you complete control over your HR data model, no enterprise partnership requirements, and a system that scales from a 5-person startup to hundreds of employees. Supabase's free tier supports up to 500MB of database storage and 2 projects, which is more than enough for a typical HR management system.

1-- Supabase SQL: run in Supabase Dashboard → SQL Editor
2
3-- Departments table
4CREATE TABLE departments (
5  id UUID DEFAULT gen_random_uuid() PRIMARY KEY,
6  name TEXT NOT NULL,
7  manager_id UUID,
8  created_at TIMESTAMPTZ DEFAULT NOW()
9);
10
11-- Employees table
12CREATE TABLE employees (
13  id UUID DEFAULT gen_random_uuid() PRIMARY KEY,
14  full_name TEXT NOT NULL,
15  email TEXT UNIQUE NOT NULL,
16  department_id UUID REFERENCES departments(id),
17  job_title TEXT,
18  start_date DATE NOT NULL,
19  status TEXT DEFAULT 'active' CHECK (status IN ('active', 'inactive', 'on-leave')),
20  created_at TIMESTAMPTZ DEFAULT NOW()
21);
22
23-- Time off requests table
24CREATE TABLE time_off_requests (
25  id UUID DEFAULT gen_random_uuid() PRIMARY KEY,
26  employee_id UUID REFERENCES employees(id) ON DELETE CASCADE,
27  start_date DATE NOT NULL,
28  end_date DATE NOT NULL,
29  type TEXT CHECK (type IN ('vacation', 'sick', 'personal', 'other')),
30  status TEXT DEFAULT 'pending' CHECK (status IN ('pending', 'approved', 'denied')),
31  notes TEXT,
32  created_at TIMESTAMPTZ DEFAULT NOW()
33);
34
35-- Enable RLS
36ALTER TABLE employees ENABLE ROW LEVEL SECURITY;
37ALTER TABLE time_off_requests ENABLE ROW LEVEL SECURITY;
38
39-- Allow authenticated users to read all employees (adjust for your needs)
40CREATE POLICY "Authenticated users can view employees"
41  ON employees FOR SELECT
42  USING (auth.role() = 'authenticated');

Gusto is the most accessible payroll API for independent developers building HR applications. Unlike ADP, Gusto offers a self-serve developer program at dev.gusto.com with a free partner sandbox environment, comprehensive REST API documentation, and standard OAuth 2.0 authentication using Bearer tokens. Gusto processes payroll for over 300,000 small businesses, making it a realistic alternative for projects targeting SMBs. To get started, create a Gusto developer account at dev.gusto.com and create an application to receive your client ID and secret. The sandbox environment includes pre-populated test companies with employees, payroll runs, and benefits data — you can test all API endpoints without touching real payroll data. Authentication uses standard OAuth 2.0 authorization code flow: redirect users to Gusto's authorization endpoint, receive the authorization code, exchange it for an access token, and store the token server-side. Gusto's API covers payroll runs (creating, calculating, and submitting payroll), employees (CRUD operations, onboarding), benefits (health insurance, 401k), time tracking (integration with time tracking tools), and contractor payments. For a Bolt.new dashboard, the most useful endpoints are GET /v1/companies/{company_id}/payroll_runs for recent payroll history and GET /v1/companies/{company_id}/employees for the employee roster. Create a Next.js API route to proxy Gusto requests — this keeps your Gusto access token server-side, away from the client bundle. The API route fetches data from Gusto's servers (outbound HTTP works fine in Bolt's WebContainer) and returns formatted data to the frontend. After deploying to Netlify or Bolt Cloud, set your GUSTO_ACCESS_TOKEN as an environment variable on your hosting platform. Note that Gusto webhooks for payroll events cannot be received during development in the WebContainer — register your webhook URL only after deploying.

1// app/api/gusto/payrolls/route.ts
2import { NextResponse } from 'next/server';
3
4const GUSTO_BASE = 'https://api.gusto.com';
5
6async function gustoFetch(endpoint: string) {
7  const token = process.env.GUSTO_ACCESS_TOKEN;
8  const res = await fetch(`${GUSTO_BASE}${endpoint}`, {
9    headers: {
10      Authorization: `Bearer ${token}`,
11      'Content-Type': 'application/json',
12    },
13  });
14
15  if (!res.ok) {
16    throw new Error(`Gusto API error: ${res.status} ${res.statusText}`);
17  }
18
19  return res.json();
20}
21
22export async function GET() {
23  try {
24    const companyId = process.env.GUSTO_COMPANY_ID;
25    if (!companyId) {
26      return NextResponse.json(
27        { error: 'GUSTO_COMPANY_ID not configured' },
28        { status: 500 }
29      );
30    }
31
32    const payrolls = await gustoFetch(
33      `/v1/companies/${companyId}/payroll_runs?processed=true`
34    );
35
36    // Format for dashboard display
37    const formatted = payrolls.map((p: Record<string, unknown>) => ({
38      id: p.uuid,
39      payPeriodStart: p.pay_period?.start_date,
40      payPeriodEnd: p.pay_period?.end_date,
41      checkDate: p.check_date,
42      totalEmployees: (p.employee_compensations as unknown[])?.length || 0,
43      grossPay: p.totals ? (p.totals as Record<string, unknown>).gross_pay : '0.00',
44      netPay: p.totals ? (p.totals as Record<string, unknown>).net_pay : '0.00',
45      status: p.processed ? 'processed' : 'pending',
46    }));
47
48    return NextResponse.json({ payrolls: formatted });
49  } catch (error) {
50    const message = error instanceof Error ? error.message : 'Failed to fetch payrolls';
51    return NextResponse.json({ error: message }, { status: 500 });
52  }
53}

Payroll systems like ADP and Gusto use webhooks to notify your application of events: payroll processed, employee onboarded, benefits enrollment completed. During development in Bolt's WebContainer, incoming webhooks cannot reach the browser-based runtime — the WebContainer has no publicly accessible URL, so ADP or Gusto's servers cannot send POST requests to it. To receive webhooks, you must deploy your application to Netlify or Bolt Cloud first. Once deployed, your app has a stable URL like https://your-app.netlify.app or https://your-app.bolt.host. Register this URL in your payroll provider's webhook settings to start receiving event notifications. For Gusto webhooks, go to your developer dashboard at dev.gusto.com, navigate to Webhooks, and add your endpoint URL (e.g., https://your-app.netlify.app/api/webhooks/gusto). Select the events you want to receive: Employee was created, Payroll was submitted, etc. Gusto sends a verification request with a secret that you must respond to with a 200 status containing the secret in the response body. For ADP webhooks (enterprise partners only), configure event notification endpoints in the ADP Marketplace developer portal. ADP sends webhook payloads signed with HMAC-SHA256 using a shared secret — always verify this signature before processing the payload. Create a separate API route for webhook handling so it is not affected by authentication middleware. Store webhook events to a Supabase table immediately on receipt and process them asynchronously to avoid timeout issues. After deploying, set your GUSTO_WEBHOOK_SECRET or ADP_WEBHOOK_SECRET as environment variables on Netlify in Site settings → Environment variables.

1// app/api/webhooks/gusto/route.ts
2import { NextResponse } from 'next/server';
3import { createHmac } from 'crypto';
4
5function verifyGustoSignature(body: string, signature: string, secret: string): boolean {
6  const expectedSig = createHmac('sha256', secret)
7    .update(body, 'utf8')
8    .digest('hex');
9  // Constant-time comparison to prevent timing attacks
10  return expectedSig.length === signature.length &&
11    expectedSig.split('').every((char, i) => char === signature[i]);
12}
13
14export async function POST(request: Request) {
15  const body = await request.text();
16  const signature = request.headers.get('x-gusto-signature') || '';
17  const secret = process.env.GUSTO_WEBHOOK_SECRET || '';
18
19  if (!verifyGustoSignature(body, signature, secret)) {
20    return NextResponse.json({ error: 'Invalid signature' }, { status: 401 });
21  }
22
23  const event = JSON.parse(body) as { event_type: string; entity_uuid: string; entity_attributes: Record<string, unknown> };
24
25  console.log(`Gusto webhook received: ${event.event_type}`, event.entity_uuid);
26
27  // Process specific event types
28  switch (event.event_type) {
29    case 'payroll.submitted':
30      // TODO: Update payroll status in your database
31      console.log('Payroll submitted:', event.entity_uuid);
32      break;
33    case 'employee.created':
34      // TODO: Sync new employee to your database
35      console.log('New employee created:', event.entity_uuid);
36      break;
37    default:
38      console.log('Unhandled event type:', event.event_type);
39  }
40
41  return NextResponse.json({ received: true });
42}