Overview
AI Apply enables you to turn job posting URLs into an API surface for creating applications. Our parser converts any application form into a standardized format that can be programmatically rendered and displayed to candidates. Fields are parsed with all necessary metadata required to render a fully fledged application form. Fields are categorized to enable auto-matching of common fields.Flows
Creating a Career Site
The career site entity is a collection of job postings. Create a new career site for each customer that you want to send applications to. Creating a career site can be done via the POST Career Sites endpoint, or in the dashboard.Parsing a Job Posting
Job posting parsing is asynchronous:- Submit job URL: POST Job Postings endpoint (or via dashboard)
- Wait for processing: Default concurrency limit of 5 jobs (reach out if you need higher limits)
- Receive webhook: Get notified when parsing completes, or poll via GET Job Postings
Adding Query Parameters
Query parameters in the job posting URL affect how the application form is generated and should be handled strategically: Best Practice: Include as many query parameters as possible in the original URL during parsing to maintain form consistency. In rare cases query parameters can affect which fields appear in the application form, so keeping them consistent ensures a stable experience for candidates. For example,?source=linkedin&utm_campaign=q1 in the parsing URL will:
- Be preserved throughout the application flow
- Potentially affect form field visibility or requirements
- Be combined with any additional parameters added during application submission
/apply call. These will be merged with the original URL parameters.
Specifying Job Location
When submitting a job posting for parsing, you can optionally include location details such as the country and postal code. Providing accurate location data ensures that applications submitted through AI Apply use the intended geolocation context. This can help avoid issues with geofencing or region-based restrictions during the submission process. If your job postings target specific locations, we recommend always including this information to maximize successful application delivery. Examples For jobs in the US, specifying the postal code ensures state-level geofencing is properly circumvented:Sending Applications
Application submission is asynchronous:- Get form & token: POST Inquiries returns the live application form and a one-time submission token. The submission token can be used for one application, and is valid for 12 hours
- Submit application: POST Apply with candidate answers (consumes the token if successful)
- Receive webhook
Query Parameters in Applications
When submitting applications via the POST Apply endpoint, you can include additional query parameters using thequery_params field. These should be application-specific parameters only (such as user IDs or tracking identifiers).
Example use cases for application-time query parameters:
- User tracking IDs (
user_id) - Session identifiers
- A/B test variants
- Application source attribution (if not already in parsing URL)
Candidate answers
Answers sent with the POST Apply endpoint are expected in the following format:| Question type | type | Example |
|---|---|---|
| TEXT | string | ”John Doe” |
| SINGLE_SELECT | string | ”BsnL4pAhNQc26uSc4JopTP3P” (Selected option ID) |
| MULTI_SELECT | string[] | [“7VMWn39TqeHRT3nW12AXMD9V”, “3Mctc15bypfL44i4KgcVrp6s”] (Selected option IDs) |
| DATE | string | ”2021-12-31T23:59:59.000Z” (ISO 8601 date) |
| NUMBER | number | 42 |
| BOOLEAN | boolean | true |
| FILE | object | { "name": "john_doe_resume.pdf", "content_type": "application/pdf", "data": "BASE64..." } |
The Application Form
The form uses a block structure with two types:- Question Blocks: Individual fields with ID, label, type (TEXT, SINGLE_SELECT, MULTI_SELECT, DATE, NUMBER, BOOLEAN, FILE), and optional conditional display
- Section Blocks: Containers grouping related questions with a
childrenarray
Application Form Example
Unified Keys
Standardized identifiers for common fields enable automatic data pre-population:Account Information
Account Information
Fields required for creating and managing user accounts, including login credentials and contact information for account access
| Key | Label | Expected Type |
|---|---|---|
EMAIL | TEXT |
Applicant Residence
Applicant Residence
Fields related to where the candidate currently lives, including full addresses, individual address components, and residence type information
| Key | Label | Expected Type | Options |
|---|---|---|---|
RESIDENCE_TYPE | Residence Type | ENUM | HOME, WORK, MAILING |
RESIDENCE_FULL_STRING | Full Residence | TEXT | |
RESIDENCE_COUNTRY | Country | ENUM | AD, AE, AF, AG, AI, AL, AM, AO, AQ, AR, AS, AT, AU, AW, AX, AZ, BA, BB, BD, BE, BF, BG, BH, BI, BJ, BL, BM, BN, BO, BQ, BR, BS, BT, BV, BW, BY, BZ, CA, CC, CD, CF, CG, CH, CI, CK, CL, CM, CN, CO, CR, CU, CV, CW, CX, CY, CZ, DE, DJ, DK, DM, DO, DZ, EC, EE, EG, EH, ER, ES, ET, FI, FJ, FK, FM, FO, FR, GA, GB, GD, GE, GF, GG, GH, GI, GL, GM, GN, GP, GQ, GR, GS, GT, GU, GW, GY, HK, HM, HN, HR, HT, HU, ID, IE, IL, IM, IN, IO, IQ, IR, IS, IT, JE, JM, JO, JP, KE, KG, KH, KI, KM, KN, KP, KR, KW, KY, KZ, LA, LB, LC, LI, LK, LR, LS, LT, LU, LV, LY, MA, MC, MD, ME, MF, MG, MH, MK, ML, MM, MN, MO, MP, MQ, MR, MS, MT, MU, MV, MW, MX, MY, MZ, NA, NC, NE, NF, NG, NI, NL, NO, NP, NR, NU, NZ, OM, PA, PE, PF, PG, PH, PK, PL, PM, PN, PR, PS, PT, PW, PY, QA, RE, RO, RS, RU, RW, SA, SB, SC, SD, SE, SG, SH, SI, SJ, SK, SL, SM, SN, SO, SR, SS, ST, SV, SX, SY, SZ, TC, TD, TF, TG, TH, TJ, TK, TL, TM, TN, TO, TR, TT, TV, TW, TZ, UA, UG, UM, US, UY, UZ, VA, VC, VE, VG, VI, VN, VU, WF, WS, YE, YT, ZA, ZM, ZW |
RESIDENCE_CITY | City | TEXT | |
RESIDENCE_STATE | State/Province/Region | TEXT | |
RESIDENCE_LINE_1 | Residence Line 1 | TEXT | |
RESIDENCE_LINE_2 | Residence Line 2 | TEXT | |
RESIDENCE_ZIP_CODE | Postal Code | TEXT |
Consent
Consent
Fields that require explicit consent or agreement from the candidate, including terms of service, privacy policies, and data usage permissions
| Key | Label | Expected Type |
|---|---|---|
APPLICANT_POOL_CONSENT | Candidate Pool Consent | BOOLEAN |
TERMS_AND_CONDITIONS | Terms and Conditions | BOOLEAN |
Personal Information
Personal Information
Fields containing basic personal details about the candidate, including names, gender, availability, and personal documents like resumes
| Key | Label | Expected Type | Options |
|---|---|---|---|
FIRST_NAME | First Name | TEXT | |
LAST_NAME | Last Name | TEXT | |
FULL_NAME | Full Name | TEXT | |
GENDER | Gender | ENUM | MALE, FEMALE, NON_BINARY, NOT_SPECIFIED |
EXPECTED_START_DATE | Expected Start Date | DATE | |
RESUME | Resume | FILE | |
BIRTH_DATE | Birth Date | DATE |
Phone
Phone
Fields related to phone numbers and telephonic contact information, including phone types, country codes, national numbers, and extensions
| Key | Label | Expected Type | Options |
|---|---|---|---|
PHONE_NUMBER_TYPE | Phone Number Type | ENUM | MOBILE, LANDLINE, WORK, HOME |
FULL_PHONE_NUMBER | Full Phone Number | TEXT | |
PHONE_COUNTRY_CODE | Phone Country Code | ENUM | AD, AE, AF, AG, AI, AL, AM, AO, AQ, AR, AS, AT, AU, AW, AX, AZ, BA, BB, BD, BE, BF, BG, BH, BI, BJ, BL, BM, BN, BO, BQ, BR, BS, BT, BV, BW, BY, BZ, CA, CC, CD, CF, CG, CH, CI, CK, CL, CM, CN, CO, CR, CU, CV, CW, CX, CY, CZ, DE, DJ, DK, DM, DO, DZ, EC, EE, EG, EH, ER, ES, ET, FI, FJ, FK, FM, FO, FR, GA, GB, GD, GE, GF, GG, GH, GI, GL, GM, GN, GP, GQ, GR, GS, GT, GU, GW, GY, HK, HM, HN, HR, HT, HU, ID, IE, IL, IM, IN, IO, IQ, IR, IS, IT, JE, JM, JO, JP, KE, KG, KH, KI, KM, KN, KP, KR, KW, KY, KZ, LA, LB, LC, LI, LK, LR, LS, LT, LU, LV, LY, MA, MC, MD, ME, MF, MG, MH, MK, ML, MM, MN, MO, MP, MQ, MR, MS, MT, MU, MV, MW, MX, MY, MZ, NA, NC, NE, NF, NG, NI, NL, NO, NP, NR, NU, NZ, OM, PA, PE, PF, PG, PH, PK, PL, PM, PN, PR, PS, PT, PW, PY, QA, RE, RO, RS, RU, RW, SA, SB, SC, SD, SE, SG, SH, SI, SJ, SK, SL, SM, SN, SO, SR, SS, ST, SV, SX, SY, SZ, TC, TD, TF, TG, TH, TJ, TK, TL, TM, TN, TO, TR, TT, TV, TW, TZ, UA, UG, UM, US, UY, UZ, VA, VC, VE, VG, VI, VN, VU, WF, WS, YE, YT, ZA, ZM, ZW |
PHONE_NATIONAL_NUMBER | Phone National Number | TEXT | |
PHONE_EXTENSION | Phone Extension | TEXT |
Conditional Rendering
Displaying Sections Conditionally
Sections should only be displayed when at least one child question’sdisplay_when condition is met
The display_when field on a question explains what condition needs to be true for the question to be displayed. Only displayed questions will be validated and must be answered.
When display_when is null, the field is not conditional and should always be displayed.
Supported Question Types
Conditional rendering is only supported by the following question types:BOOLEAN- Shows/hides fields based on true/false valuesSINGLE_SELECT- Shows/hides fields based on selected option IDMULTI_SELECT- Shows/hides fields when ANY of the specified option IDs are selected
answer_equals property matches the answer format expected in the POST Apply endpoint:
View examples of when to render a conditional field
View examples of when to render a conditional field