What it takes to apply to jobs programmatically.

The phrase “jobs API” usually describes an index: send filters, get openings. That is the right primitive for a job board, labor-market analysis, matching, or an agent deciding which roles deserve attention. It is not a submission primitive.

A job application APIaccepts an authorized candidate's data and creates a durable application against a real employer form. That difference introduces candidate state, documents, consent, dynamic schemas, side effects, retry safety, and an outcome that may arrive later.

Apply Guy's Developer API v1 scopes that contract to U.S. catalog jobs and U.S.-normalized candidate profiles. A caller can provide a supported employer URL discovered elsewhere, but remains responsible for choosing a U.S.-appropriate role.

A production application API should expose these pieces explicitly:

# Search is the read path
GET /v1/jobs?q=backend%20engineer&country=US&limit=25

# Preflight makes readiness and cost explicit
POST /v1/applications/preflight
{
  "jobId": "951f7024-bbf7-4aa5-98fc-f45625584f9b",
  "mode": "managed"
}

# Create is the write path
POST /v1/applications
Idempotency-Key: candidate-42-job-951f7024-v1
{
  "jobId": "951f7024-bbf7-4aa5-98fc-f45625584f9b",
  "mode": "managed"
}

Notice the idempotency key. Network timeouts are ordinary. Without a caller-defined identity for the logical operation, retrying a timed-out POST can reserve credits twice or send a duplicate employer application. Apply Guy requires the header on every application create and returns the existing application for the same key.

A job description does not tell you which fields the application will require. Two openings on the same hiring platform can ask different knockout questions, expose different location or education selectors, and require different documents. The schema has to be discovered from the specific form.

That discovery should be open-ended. A parser that only recognizes known field names will silently miss the next employer-specific question. A robust system surfaces every field, maps candidate facts directly where possible, and sends only genuinely ambiguous questions to a resolver.

Browser automation is a useful fallback, but it is an expensive default for a developer API. It adds browser startup, DOM timing, viewport state, frontend re-renders, and a larger failure surface to every request.

An HTTP-first executor reproduces the hiring platform's actual network contract: fetch the form, maintain the session, upload files, generate required tracking fields, solve verification when necessary, and serialize the exact submission payload. It is faster and more deterministic when the platform exposes that path.

Apply Guy hides those ATS-specific contracts behind one application resource across 13 supported hiring platforms. “Supported” still matters: preflight can reject a disabled platform or flag an inbox integration before credits are reserved.

The executor knows how to represent a selected option, upload a resume, preserve a session, and send the form. An AI model knows how to interpret an open-ended question in context. Combining both responsibilities inside an opaque “auto apply” call makes the system harder to inspect and harder to customize.

Apply Guy exposes two modes. Managed mode uses its resolver and costs 2 credits, or $0.10 at 20 credits per dollar. Agent mode pauses at ambiguous questions, returns a prompt and JSON Schema, and costs 1 credit, or $0.05. Your model controls the answer; Apply Guy controls the form protocol.

A single boolean called submitted throws away the information an agent needs. A useful lifecycle includes:

Webhooks should sign the raw body, include a timestamp, and expose a delivery ID for deduplication. Polling remains valuable for recovery and simple clients. Supporting both means an agent can react quickly without trusting that a single webhook delivery will always arrive.

• Does it submit, or only redirect? A redirect URL is not an application write path.
• Is the exact employer form discovered? Static question templates age badly.
• Can you preflight without being charged? Platform and profile blockers should be visible first.
• Are create requests idempotent? This is essential for any paid external side effect.
• Can you bring your own model? Teams with domain policies should not have to surrender answer generation.
• Are outcomes durable and machine-readable? A transient success toast is not enough for an agent.
• Can users cancel before submission? Control should survive after the queue call.
• How are credits handled on known failures? The charging boundary should be documented.

The common thread is deliberate authorization. The user or product decides which application should exist; the API removes the repetitive mechanics after that decision.