How to build employer self-service workflows

Create and claim companies, manage jobs, applicants, pipeline stages, billing, and messaging.

Employer routes sit behind a board-user session and company authorization. Load company membership first and pass the current access token per call. Never use a shared stateful SDK client for employer requests.

Create the employer home

1const options = {
2  cache: 'no-store' as const,
3  headers: { authorization: `Bearer ${accessToken}` },
4};
5
6const companies = await board.me.companies.list(options);

If the user has no company, offer create, search, or claim paths according to board.context().features. Creating a company and claiming an existing company are distinct workflows; do not guess ownership from an email domain.

Verify work email and claims

Use board.me.companies.workEmail.verify to email the challenge, then board.auth.verifyWorkEmail({ token }) to consume the emailed token. The link carries no company slug and needs no session. Use claim and cancelClaim for the company ownership workflow. Show the returned status and next action; do not treat a pending claim as active employer access.

Manage company jobs

1const { data: memberships } = await board.me.companies.list(options);
2const membership = memberships.find(
3  ({ company }) => company.slug === requestedCompanySlug,
4);
5
6if (!membership || membership.status !== 'approved' || !membership.company.slug) {
7  throw new Response('Forbidden', { status: 403 });
8}
9
10const companySlug = membership.company.slug;
11const [jobs, billingOptions] = await Promise.all([
12  board.me.companies.jobs.list(companySlug, { limit: 50 }, options),
13  board.me.companies.billingOptions.list(companySlug, options),
14]);

The membership list is the source of truth for companies this user can manage; board.me.companies.search({ q }) is only for finding a company to claim. Create or update a draft, then complete checkout when required. Branch on checkout, published, pending_approval, or invoice_sent — a free post on a moderated board waits in pending_approval and is not public. Unpublish and delete are separate actions with separate availability. After a mutation, reload the job from board.me.companies.jobs.retrieve and render the server state.

Build the applicant pipeline

Use board.me.companies.applicants.list for the current queue. Move or reject one applicant with the focused methods; use bulk methods only after the user selects explicit application IDs. Pipeline stage create, update, reorder, and remove calls are company-scoped and private.

Saved talent predicates live on board.me.companies.talentLists. Per-job sourced membership lives on board.me.companies.sourcedCandidates. Convert-on-drop calls sourcedCandidates.convert rather than inserting a sourced stage on the pipeline.

Add employer messaging

Start an application conversation with board.me.conversations.startAboutApplication. List and reply through the conversation namespace. Keep unread counts and archive state sourced from the API; do not infer them from the messages currently rendered.

Verify the employer journey

Test a user with no company, a pending claim, an active company, and access to two companies.
Attempt a cross-company job and applicant request and confirm the API denies it.
Create a draft, complete the required billing step, and verify the result: a free post is published or pending_approval; a paid plan is checkout. Do not treat HTTP 200 as live.
Move an applicant through reordered stages and reload the pipeline after each mutation.
Start a conversation about an application and confirm only authorized company members can read it.

Continue with Monetization and paywalls to connect plans, posting products, and candidate access.