Job Board Partner Integration

Start With the Interface You Already Have

Kit can connect to a job board without asking the board to adopt a Kit-specific protocol. If you already operate a partner API, XML feed importer, OAuth flow, taxonomy endpoint, moderation callback, or external-apply contract, we will integrate with that.

This guide is a discovery checklist, not a specification imposed on partners. Its purpose is to make the first technical conversation shorter: it shows what Kit can provide today, which decisions usually need to be made, and where we can adapt to your existing process.

Integration Shapes

Most partnerships use one or more of these shapes:

Shape	Best when	Kit provides
Push to the board’s API	The board already has an employer or multiposting API	Create, update, pause/close, and status synchronization through a board-specific adapter
Board pulls a feed	The board ingests tenant or ATS feeds on a schedule	A public, cacheable per-employer XML feed; we add the board’s dialect against its authoritative schema
External application link	The board sends candidates to the employer’s ATS	A stable job URL or direct application URL with source attribution
Native apply into Kit	The board collects the application and is approved to forward it	A tenant-scoped server API, presigned resume upload flow, form schema, and PII-free submission receipt

We can start with the simplest supported shape and add richer status or application synchronization later. A pull feed does not require the board to implement Kit’s push model, and a push integration does not require the board to consume one of Kit’s existing feed dialects.

Formats Kit Already Provides

Public XML and Atom Feeds

Every hosted career portal has a per-employer feed containing only jobs that are currently accepting applications:

https://startupkit.app/careers/example/jobs.xml
https://startupkit.app/careers/example/jobs/atom

Custom career domains expose the same feeds at /jobs.xml and /jobs/atom. Kit currently renders Adzuna, Atom 1.0, Jooble, Jobrapido, and Uitzendbureau dialects. Those formats demonstrate the data available; we do not assume another board accepts any of them. Once a partner supplies its schema and sample payloads, Kit can render a dedicated dialect at a stable URL.

Feed entries use a stable public job identifier and can include:

• title and HTML description;
• employer name, department/category, location, and remote status;
• publication and update dates;
• employment type;
• salary minimum, maximum, currency, and period when disclosed;
• public job and direct-application URLs with partner-specific UTM attribution.

Pausing or closing a role removes it from the feed. Reopening it restores the same stable job identity. Content edits update the existing entry rather than creating a second role.

Public Jobs REST API

The Public Jobs API offers JSON over HTTPS for a server-side or browser integration:

GET /api/public/v1/jobs
GET /api/public/v1/jobs/:public_token
POST /api/public/v1/jobs/:public_token/applications

The list returns only published jobs. The detail response adds the sanitized HTML description and the employer’s application-form schema. Each employer creates a tenant-scoped key pair; server integrations use the secret sk_… key. Neither key can read candidate records.

Native application forwarding is agreed separately because the board must preserve required questions, resume constraints, consent disclosures, bot protection, and the candidate’s real source. Where a board already supports an external ATS URL, redirecting candidates to Kit is usually the fastest and cleanest first release.

JobPosting Structured Data

Every public job page includes server-rendered schema.org/JobPosting JSON-LD. It carries the job description, posting dates, employer, location or remote requirements, employment type, salary when present, direct-apply status, and canonical URL.

JSON-LD is useful for discovery and validation. It is not a substitute for an agreed publishing API, feed schema, moderation status, or lifecycle callback.

Signed Lifecycle Webhooks

Kit can send signed webhooks when a job is:

• job_posting.published
• job_posting.paused
• job_posting.closed
• job_posting.reopened

The event identifies the tenant and job and includes its current status and public URL. A partner can use it as an invalidation signal, then refetch the canonical job from the agreed feed or API. See Webhooks Overview and Webhook Security and Delivery.

Canonical Job Data

Kit’s existing publication surfaces can provide this core contract:

Field	Notes
Stable job ID	The public token remains stable across edits, pause, and reopen
Title and description	Plain title plus sanitized HTML description
Employer	Tenant name; logo and website are available from the employer profile
Department/category	Employer-authored value, mapped to the board’s taxonomy when required
Location and remote	Free-text location plus a remote flag and optional applicant country
Employment	Employment type; partner-specific contract values can be collected during mapping
Compensation	Minimum, maximum, ISO currency, and hour/day/month/year period when disclosed
Dates	Published and last-updated timestamps; closed jobs leave active feeds
URLs	Canonical job URL and direct application URL
Application form	Required fields, screening questions, consent disclosure, and resume constraints

Boards often require additional controlled data such as seniority, skills, languages, category IDs, multiple locations, contract taxonomies, privacy notices, or paid-package options. We map or collect those fields in the integration’s review step rather than forcing them into a lossy generic value.

What We Need From a Partner

Send whatever documentation and workflow you already use. The checklist below helps us spot gaps early; it is fine if some items do not apply.

• Technical and commercial contacts
• API, feed, or multiposting documentation plus sample requests and responses
• Sandbox credentials or a safe test account
• Authentication, key rotation, scopes, rate limits, and IP requirements
• Category, location, seniority, skill, contract, and salary taxonomies
• Required versus optional fields and validation rules
• Create, edit, publish, pause/close, reopen, and expiry behavior
• Idempotency, retry, duplicate-prevention, and error semantics
• Moderation statuses plus polling or callback support
• External-apply or native-apply rules, source attribution, privacy, and retention
• Package ownership, credit consumption, brand selection, and test-credit rules
• Production approval, certification, and support process

Security and Candidate Data

• Public feeds and job-list endpoints contain job data, never candidate PII.
• Credentials are tenant-scoped; server secrets are not exposed to browsers.
• Webhooks are signed and replay-protected.
• Application data is accepted only through an agreed intake or the employer’s own Kit application page.
• We do not build partner integrations by scraping private or undocumented endpoints.

Start a Partnership

Email [email protected] with your existing integration guide or the name of the person who owns it. We will reply with a concise field mapping and the smallest useful pilot for both teams.

Quick Checklist

• Pick push API, pull feed, external apply, native apply, or a combination
• Share the board’s existing contract and a sandbox path
• Agree field/taxonomy mappings and credit behavior
• Test create, edit, close, error, and moderation paths
• Verify source attribution and candidate privacy
• Launch with a small paid pilot, then monitor status and applications