ATS Partner API

This API lets ATS (Applicant Tracking System) partners integrate Omogen as a third-party service to run pre-qualification and reactivation interviews with their candidates. It provides endpoints to sync job offers and create interview processes, plus webhooks to receive evaluation reports.

Download the OpenAPI spec

This page is generated from an OpenAPI 3.0 spec, available for download: 📄 JSON · 📄 YAML

Omogen automates phone interviews with candidates through its conversational agent Mio, evaluates how well they match the selection criteria, and generates detailed reports to support recruiters in their decision-making.

Self-serve configuration

The integration is created and configured directly from the Omogen app — no need to go through support. See Creating the integration. If you have any questions, you can still reach us at gillian@omogen.ai.

Creating the integration

The "Custom API" integration is created in a few clicks from the Omogen app:

1. Open the Integrations menu.
2. Click New integration (+).
3. Pick Custom (the custom API integration) from the list of available connectors.
4. Fill in the parameters (see below), then confirm.

As soon as it is created, Omogen automatically generates your two keys (API key and partner key): they appear on the integration page, ready to copy. You no longer need to request them from support.

You can reopen the integration page at any time to copy your keys, edit the configuration, or disable the integration (disabling replaces deletion: the configuration and history are preserved).

Configuration parameters

Parameters are grouped into three sections.

Connection

Parameter	Editable	Description
API key	❌ (generated)	Bearer key generated by Omogen — display and copy only.
Partner key	❌ (generated)	Key sent in the OM-PARTNER header — display and copy only.
Agency ID (agency_id)	✅	Optional. Lets you distinguish several bridges sharing the same keys (leave empty if unused).
Base URL (base_url)	✅	URL of your endpoint that will receive the webhooks (reports, callbacks). Required if webhooks are enabled.

Webhooks

Parameter	Description
Send report webhook (send_report_created_webhook)	Enables sending a webhook to your endpoint when a report is generated (enabled by default).
Include transcript and recording in the webhook (include_transcript_and_recording)	Optional (disabled by default). Adds the per-call breakdown (calls[]) to the report_generated webhook: transcript and S3 recording URL for each call. See report_generated.
HTTP method (webhook_http_method)	PUT (default) or POST.
Webhook headers (webhook_headers)	Key/value pairs added to every request (typically your authentication header, e.g. x-api-key).
Send the call_booked webhook (send_call_booked_webhook)	Optional. Also sends a webhook when a candidate books a slot.
Dedicated call_booked URL (call_booked_webhook_url)	Optional. Separate URL for call_booked callbacks (the base URL is used by default).

Advanced

Parameter	Description
Job fetch URL (job_fetch_url)	Pull flow only. URL template for your endpoint; must contain the {job_id} placeholder (e.g. https://api.partner.com/v1/jobs/{job_id}).
Fetch headers (job_fetch_headers)	Pull flow. Key/value pairs added to job fetch requests (e.g. Authorization).
Signing secret (job_fetch_secret)	Pull flow. Shared secret used to sign requests with HMAC-SHA256 (see Request signing).
Default triage config (default_triage_config_id)	Optional. UUID of a triage configuration used to route candidates to job offers through CV analysis.

Which flow should you choose?

The "Advanced" parameters only apply to Flow 2 (Pull). For Flow 1 (Push) and Flow 3 (Direct), only the Connection and Webhooks sections are needed. See the comparison of the three flows.

Authentication

Authentication relies on two distinct keys:

1. An Omogen API key sent in the Authorization header as a Bearer token
2. A partner key sent in the OM-PARTNER header to identify the ATS partner

Required headers

Authorization: Bearer <API_KEY>
OM-PARTNER: <PARTNER_KEY>

Example

curl -X GET https://api.omogen.ai/api/v1/integration-partner/interview-params \
  -H "Authorization: Bearer sk_partner_abc123xyz..." \
  -H "OM-PARTNER: partner_xyz" \
  -H "Content-Type: application/json"

Key management

Both keys are generated automatically when you create the integration in the Omogen app. Each key pair is tied to a specific organization. You can retrieve them at any time from the integration page (Integrations menu) — display and copy only, without support involvement.

• Partner key: sent in the OM-PARTNER header, it identifies where requests come from.
• API key: sent in the Authorization header as a Bearer token.

Integration flows

Omogen offers three integration modes. The right one depends on who owns the job repository and how much information the partner can send upfront.

Comparison of the three flows

Aspect	Flow 1: Push	Flow 2: Pull	Flow 3: Direct
Who owns the jobs?	The partner (ATS)	The partner (ATS)	Omogen — jobs created in the Omogen interface
What must the application contain?	external_job_id + (optional) job_title / job_description	external_job_id only (Omogen fetches the details)	job_opportunity_id (Omogen UUID)
Partner-side complexity	Low (outbound API calls only)	Medium (endpoint to implement)	Low — no job management on the partner side
Prerequisites	No endpoint to build	Job read endpoint required	Jobs are created by recruiters in the Omogen interface
Omogen configuration	API keys only	API keys + endpoint URL + partner credentials	API keys only

Mutually exclusive choices

A call to POST /applications (or /applications/cv-only) can use only one job resolution mode: either external_job_id (Flows 1 & 2), or job_opportunity_id (Flow 3), or neither for triage mode. Sending both external_job_id AND job_opportunity_id returns 400 INVALID_PAYLOAD.

Flow 1: Push (partner-driven sync)

The ATS partner syncs job offers before sending applications.

Flow 2: Pull (Omogen-driven fetch)

The partner sends applications directly. Omogen automatically retrieves the job offer details from an endpoint exposed by the partner.

Configuring Flow 2 in Omogen

To enable Flow 2 (Pull), configure the following parameters in the Advanced section of the integration page (Integrations menu → your integration → Edit):

Parameter	Description
job_fetch_url	URL template for the partner endpoint. Must contain the {job_id} placeholder, which Omogen replaces with the external_job_id at call time (e.g. https://api.partner.com/v1/jobs/{job_id})
job_fetch_headers	Static headers injected into every request (e.g. {"Authorization": "Bearer <partner_api_key>"}). Used for standard partner-side authentication.
job_fetch_secret	Shared secret used to sign every request with HMAC-SHA256 (optional but recommended). See the "Request signing" section below.

Endpoint to implement (Flow 2)

Endpoint: GET <job_fetch_url>, where the {job_id} placeholder is replaced with the external_job_id sent in POST /applications.

Headers sent by Omogen:

<headers configured in job_fetch_headers>
Content-Type: application/json
OM-OMOGEN-TIMESTAMP: <unix_timestamp>
OM-OMOGEN-REQUEST: <hmac_sha256_signature>

Request signing (recommended)

When job_fetch_secret is configured, Omogen signs every request so the partner can verify where the call came from. The partner should recompute the same signature on their side and compare it with the OM-OMOGEN-REQUEST header.

timestamp = str(int(unix_time_seconds))
payload   = f"{timestamp}.{external_job_id}"
signature = HMAC_SHA256(secret=job_fetch_secret, message=payload).hexdigest()

Replay protection

The timestamp is in Unix seconds. We recommend rejecting requests whose timestamp differs by more than 5 minutes from the partner's server time, to limit replay attacks.

Expected response (200 OK)

{
  "job_title": "Full Stack Python/React Developer",
  "job_description": "We are looking for an experienced full stack developer...",
  "metadata": {
    "department": "Engineering",
    "location": "Paris",
    "contract_type": "Permanent"
  }
}

Field	Type	Required	Description
job_title	string	✅	Job title
job_description	string	✅	Full job description (min. 100 characters recommended)
metadata	object	❌	Free-form additional fields (stored as metadata in Omogen)

Error codes expected on the partner side

Partner code	Description	Omogen code returned to the partner
200	Success	Job created/updated
404	Job not found	400 JOB_FETCH_NOT_FOUND
4xx/5xx	Partner server error	502 JOB_FETCH_HTTP_ERROR
timeout/network	Network error	502 JOB_FETCH_NETWORK_ERROR
Invalid JSON	Unparsable response	502 JOB_FETCH_INVALID_RESPONSE
200 without job_title	Required field missing	502 JOB_FETCH_MISSING_TITLE

Flow 3: Direct (jobs created in Omogen)

For partners without an ATS who create their job offers directly in the Omogen interface, the API accepts a job_opportunity_id (Omogen UUID) instead of an external_job_id. No mapping is created on the Omogen side — the application points directly at the existing job.

The job_opportunity_id is scoped to the organization: sending a UUID that points to a job belonging to another organization returns 400 JOB_OPPORTUNITY_NOT_FOUND.

Custom candidate fields (enrichment_data)

POST /applications and POST /applications/cv-only accept an optional enrichment_data field: a dictionary of custom values attached to the candidate, usable by the voice agent during the call and in your SMS / email templates.

What it's for

Each organization can declare a set of enrichment variables (custom candidate fields). Typical examples:

• date_candidature: when the candidate started their application
• lien_invitation: deep-link URL to their partner portal
• persona, ville_de_residence, score_quiz, etc.

These values are available on the Omogen side as Jinja variables {candidate_<name>}:

• in the voice agent prompt: "I can see you started your application on {candidate_date_candidature}…"
• in SMS, email and WhatsApp templates: "Here is the link to finish: {candidate_lien_invitation}"

Expected format

{
  "external_application_id": "APP-456",
  "job_opportunity_id": "c8d3a4f2-...",
  "external_candidate_id": "CAND-789",
  "first_name": "Marie",
  "last_name": "Dubois",
  "email": "marie.dubois@example.com",
  "enrichment_data": {
    "date_candidature": "on 14 March",
    "noms_documents_manquants": "CV and ID card",
    "lien_invitation": "https://partner.example.com/signup/CAND-789"
  }
}

• Keys match the name (snake_case) of the EnrichmentVariable records declared on your organization.
• Values are always strings, even for numbers or dates (the agent reads them as-is).
• The field is optional: omitting it changes nothing in the current behaviour.

Merge semantics

• On candidate creation: values are set on Candidate.additional_info.
• On update (re-sending with the same external_candidate_id): the keys you send are merged into the existing values. Keys you do not send are preserved.
• To blank out a key, explicitly send an empty string "".

Recommended pre-conversion

Values are read aloud by the agent. Pre-convert on the partner side anything that does not read naturally:

Avoid	Prefer
"2026-03-14" (ISO) → the agent says "two thousand twenty six dash zero three…"	"on 14 March" or "3 months ago"
["cv", "id_card"] (JSON list / internal IDs)	"CV and ID card"
12345.67 (raw number without context)	"12,345 euros"

Unknown keys

If a key is not declared as an EnrichmentVariable on your organization (or on the parent corporation), the call returns 400 UNKNOWN_ENRICHMENT_VARIABLE. Available variables are created from the Omogen app, or by Omogen through support for the initial bootstrap. Once created, they are immediately usable through the API.

Candidate invitation link

For deployment modes where the candidate schedules themselves (no immediate outbound call), Omogen generates an invitation link in the form https://agent.omogen.ai/invitation/{process_id}. The candidate clicks this link to pick an interview slot.

Deployment modes with an invitation link

Mode	Behaviour
email-invitation	Omogen sends the candidate an email with the link
sms-invitation	Omogen sends the candidate an SMS with the link
whatsapp-invitation	Omogen sends the candidate a WhatsApp message with the link
invitation-link-only	Omogen sends nothing — the partner displays the link in their own interface

When to use invitation-link-only

Choose this mode if you want full control over communication with the candidate (for example displaying it in your own candidate portal or recruiter dashboard). The process is created with status active and automatically expires after 10 days without a booking, like the other invitation modes.

Retrieving the link from the response

POST /applications (and /applications/cv-only) return the link in the data.invitation_link field whenever the resolved deployment mode is an invitation mode:

{
  "success": true,
  "message": "Application synchronized and process created successfully",
  "data": {
    "process_id": "9b6e81e0-5736-4106-ba8b-86df6a43b663",
    "status": "in_progress",
    "invitation_link": "https://agent.omogen.ai/invitation/9b6e81e0-5736-4106-ba8b-86df6a43b663",
    "..." : "..."
  }
}

For call-oriented modes (single-call, sms-then-call, 3-days, reactivation, whatsapp-then-call, cv-only), invitation_link is null: the invitation page exists but the booking form is not enabled for those processes, so showing the link would send the candidate to a non-functional page.

Endpoint reference

The following section is generated automatically from the OpenAPI specification openapi-partenaires.yaml.

Get Interview Params

Sync a Job Offer

Sync an Application

Sync a CV-only Application

Error codes

All endpoints return an error payload in the ErrorResponse format:

{
  "success": false,
  "error": "Human-readable message",
  "code": "MACHINE_READABLE_CODE"
}

The POST /applications/cv-only endpoint can also return a details field with diagnostic information (URL, HTTP status, technical reason).

Cross-cutting codes

Code	HTTP status	Description
AUTHENTICATION_FAILED	401	Invalid or missing API key, unrecognised partner
INVALID_PAYLOAD	400	Malformed payload (missing fields, invalid format)
VALIDATION_ERROR	400	Generic business validation error
INTERNAL_ERROR	500	Unexpected server error

Codes specific to POST /applications

Code	HTTP status	Description
JOB_OPPORTUNITY_NOT_FOUND	400	Direct flow — the job_opportunity_id does not match any job in the organization tied to your bridge
JOB_FETCH_NOT_FOUND	400	Pull flow — the partner ATS returned 404 for the external_job_id
PULL_FLOW_CONFIG_ERROR	400	Pull flow — job_fetch_url misconfigured (missing {job_id} placeholder)
CV_DOWNLOAD_FAILED	400	Failed to download the CV from cv_url
CV_DECODE_FAILED	400	cv_file is not valid base64
CV_TOO_LARGE	400	The decoded CV exceeds the maximum size (10 MB)
UNKNOWN_ENRICHMENT_VARIABLE	400	An enrichment_data key is not declared as an EnrichmentVariable on the organization (or the parent corporation). See Custom candidate fields.
JOB_FETCH_NETWORK_ERROR	502	Pull flow — network error while contacting the partner ATS
JOB_FETCH_HTTP_ERROR	502	Pull flow — the partner ATS returned a 4xx/5xx status
JOB_FETCH_INVALID_RESPONSE	502	Pull flow — unparsable response (invalid JSON)
JOB_FETCH_MISSING_TITLE	502	Pull flow — the response does not contain job_title

Codes specific to POST /applications/cv-only

Code	HTTP status	Description
CV_DOWNLOAD_FAILED	400	Failed to download the CV (cv_url unreachable or cv_file invalid base64)
CV_INVALID_INPUT	400	The CV content is not a valid document
CV_EXTRACTION_FAILED	400	CV parsing failed (unrecognised format, unreadable content)
CV_PROCESSING_ERROR	400	Internal error during extraction
CV_EXTRACTION_UNEXPECTED_ERROR	400	Unexpected error during extraction

Webhooks

Webhooks are sent by Omogen to an HTTP endpoint configured on the partner side. The partner must respond with a 2xx status to acknowledge receipt.

Configuration

The webhook URL and authentication headers are configured directly on the integration page (Integrations menu → your integration → Edit, Webhooks section). See Configuration parameters.

Parameters configurable per organization:

Parameter	Description
Webhook URL (base_url)	HTTP endpoint to call (used for report_generated and process_rejected)
HTTP method (webhook_http_method)	PUT (default) or POST
Custom headers (webhook_headers)	Authentication headers provided by the partner (e.g. x-api-key, Authorization)
Authentication mode	Static headers (default) or OAuth 2.0 (client credentials) — see Webhook authentication
call_booked URL (optional)	Dedicated endpoint for call_booked events (if separate from the main URL)

Timeout: 30 seconds. No automatic retry — if the partner endpoint fails, the webhook is lost (though the incident is logged on the Omogen side).

Webhook authentication

By default, Omogen authenticates its outbound webhooks using the static headers you provide (typically an x-api-key). If your endpoint is protected by OAuth 2.0, Omogen can instead obtain a bearer token and send it on every call.

Static headers (default)

No specific configuration: the custom headers configured for your organization are sent as-is on every webhook. This is the behaviour of all existing integrations.

OAuth 2.0 (Client Credentials)

An opt-in option, enabled per integration. You provide Omogen with the following parameters (through the integration settings or Omogen support):

Parameter	Required	Description
token_url	✅	URL of your identity provider's OAuth 2.0 token endpoint (e.g. https://idp.partner.com/oauth/token)
client_id	✅	OAuth 2.0 client ID
client_secret	✅	OAuth 2.0 client secret (stored encrypted on the Omogen side, never displayed again)
scope	❌	Scope(s) to request, space-separated (if your IdP requires them)
audience	❌	audience parameter (required by some IdPs, e.g. Auth0)

How it works:

1. Before sending a webhook, Omogen requests a token from token_url using Client Credentials:

   POST <token_url>
   Content-Type: application/x-www-form-urlencoded
   
   grant_type=client_credentials&client_id=<client_id>&client_secret=<client_secret>

   (with scope and/or audience if configured). The expected response is a JSON { "access_token": "...", "expires_in": 3600 }.

2. Omogen adds the Authorization: Bearer <access_token> header to every webhook. Your static headers (e.g. x-api-key) are still sent in addition — the two coexist.

3. The token is cached until shortly before it expires (expires_in − 60 s), so Omogen does not call your token_url on every webhook.

4. If your endpoint responds 401 or 403, Omogen invalidates the cached token and retries once with a fresh one.

IP restrictions

If your token_url or webhook endpoint filters by IP, contact support to get the list of Omogen outbound IPs to allow.

report_generated

Sent when a process reaches a terminal state. This is the main event to implement on the partner side.

The payload you receive

{
  "event_type": "report_generated",
  "timestamp": "2026-08-27T10:15:00Z",
  "process": {
    "id": "<uuid>",
    "status": "active | in_progress | completed | incomplete | canceled | expired | failed",
    "failure_reason": { "code": "...", "message": "..." },   // or null
    "use_case": "prequalification | reactivation",
    "created_at": "2026-08-27T09:00:00Z"
  },
  "external_application_id": "<your application id>",
  "external_candidate_id":   "<your candidate id>",
  "external_job_id":         "<your job id>",                // or null
  "job_title": "Room attendant",                             // or null

  "reports": {
    "interview_report": {                                     // null if no interview
      "status":        "match | no_match | na",               // ← actionable decision
      "report_status": "in_progress | completed | failed",
      "overall_score": 0.83,                                  // ← float 0.0–1.0, NOT out of 100
      "is_complete":   true,
      "summary":       "free text — do not parse",
      "evaluations": [
        {
          "criteria_id":   "<uuid>",
          "criteria_name": "Hospitality experience",
          "value":         "5 years",                         // ← string, number, boolean,
          "is_mentioned":  true,                              //   array or object
          "is_satisfied":  true,
          "is_knockout":   false                              // eliminatory criterion
        }
      ],
      "data_points": [                                        // informational, no pass/fail
        {
          "criteria_id":   "<uuid>",
          "criteria_name": "Availability",
          "value":         "immediate",
          "is_mentioned":  true
        }
      ]
    },
    "cv_report": {                                            // null if no CV
      "status":        "completed | failed",
      "match_result":  "match | no_match",
      "overall_score": 0.71
    }
  },

  "appointment": { "scheduled_at": "...", "duration_minutes": 30 },  // or null
  "tags": [],                                                        // see "Call tags"
  "report_url": "https://app.omogen.ai/report/<uuid>",
  "consent": { "status": "valid | invalid | not_collected" },        // or null
  "calls": [                                                         // null if option disabled
    {
      "started_at":    "2026-08-27T09:05:00Z",                       // or null
      "status":        "completed | failed | reporting",
      "duration_ms":   329274,
      "transcript":    "AI: ...\nUser: ...",
      "recording_url": "https://s3..."                               // or null
    }
  ]
}

The two fields to rely on

reports.interview_report.status (match / no_match / na) and overall_score (0–1) are the only decision fields. Their contract is stable. See The summary field for why the text must never drive automated processing.

Detailed reference

The full schema below is generated from the OpenAPI spec. The "Request" block describes the payload Omogen sends you; the "Response" block describes what your endpoint must return — a 2xx status is enough, the body is ignored.

When is the webhook sent?

Process status	interview_report present?	When?
completed	Yes (complete)	After report generation, all criteria evaluated
incomplete	Yes (partial)	After report generation, some criteria missing
failed	No (null)	Technical failure, early hang-up, attempts exhausted
expired	No (null)	Process expired (deadline passed)
canceled	No (null)	Process cancelled manually

INFO

It is possible (though rare) for a candidate to call back after a terminal state has been reached. In that case the process returns to in_progress, a new interview takes place and a new webhook is sent. We therefore recommend always processing the webhooks you receive, even if you have already received a terminal state for that process_id.

Transcript and recording (optional)

If the Include transcript and recording in the webhook option (include_transcript_and_recording) is enabled on your integration, the report_generated payload contains a calls[] array describing every call of the process, in chronological order (one entry per call — retries and resumed interviews are all listed):

Field (calls[])	Description
started_at	Call start time (ISO 8601), null if the call never started.
status	Call status (completed, failed, reporting…).
duration_ms	Call duration in milliseconds.
transcript	Call transcript, as line-by-line speaker turns in the format "<Speaker>: <text>" — AI = the Omogen agent, User = the candidate (one turn per line, separated by \n). Always populated with the text actually collected — partial transcripts of failed/incomplete calls are preserved; empty string if there is no transcript.
recording_url	S3 URL of the call's audio recording, null if there is none.

The calls field is null as long as the option is not enabled for your integration (so existing integrations keep their current contract), and an empty list [] if the option is enabled but the process had no call. To enable it, tick the box in the Webhooks section of the integration page (see Configuration parameters).

Example — fragment of a report_generated payload with calls[]:

{
  "event_type": "report_generated",
  "external_application_id": "APP-123",
  "calls": [
    {
      "started_at": "2026-07-03T14:30:00Z",
      "status": "completed",
      "duration_ms": 184000,
      "transcript": "AI: Hello, this is Mio, I'm calling about your application.\nUser: Yes hello, I'm available.\nAI: Great, a few quick questions to start with.",
      "recording_url": "https://s3.eu-west-3.amazonaws.com/omogen-recordings/2f9c...e1.mp3"
    }
  ]
}

Call tags

A list of signals detected automatically while analysing the conversation. The list is empty ([]) if no signal was detected.

Tag	Description
early_hang_up	The candidate hung up before any useful information could be collected
prefers_recruiter	The candidate asked to speak to a human recruiter
not_interested	The candidate explicitly said they were not interested in the role
not_available	The candidate said they were not available for the call
to_review	The conversation is inconsistent and requires manual review

failure_reason codes

Code	Description
cv_required	CV required but not provided
cv_screening_failed	CV screening failed (technical error)
cv_requirements_not_configured	No CV criteria configured for this job offer
technical_error	Internal technical error
all_attempts_failed	All call attempts failed (no answer)
early_hang_up	The candidate hung up too early to collect any information

call_booked

Sent when a candidate has booked a call slot through self-scheduling (SMS or email). Only enabled if the feature is configured for the organization.

process_rejected

Sent when a candidate is rejected before a process is created (eligibility check failure, triage rejection). No call is placed and no report is generated.

Statuses and behaviour

Process statuses

• in_progress: The process is running (calls, SMS, etc.)
• active: The process is active and waiting for an action (e.g. SMS invitation awaiting a booking)
• completed: The process finished successfully
• incomplete: The process could not be completed (e.g. no call went through)
• failed: The process failed (technical error, connection issue)
• expired: The process expired (deadline passed)
• canceled: The process was cancelled manually

Interview report statuses

• match: The candidate matches the selection criteria
• no_match: The candidate does not match the selection criteria
• na: The interview did not make it possible to determine the candidate's status

The interview report also includes:

• report_status: in_progress, completed, or failed
• overall_score: Overall score between 0 and 1 — 0.83 means 83 %, the scale is not out of 100
• is_complete: Whether the report is complete (all criteria evaluated)
• summary: Written summary of the interview, as free text (see below)

The summary field

summary is the written summary of the interview. Since 21 August 2026, it expresses a level of alignment with the role rather than a binary recommendation:

overall_score	Wording
≥ 0.90	fully aligned
≥ 0.70	highly aligned
≥ 0.50	partially aligned
< 0.50	weakly aligned
—	not enough information (the interview did not allow a conclusion)

The terms "recommended" and "not recommended", used until 20 August, are no longer used.

Do not build any logic on summary

This field is meant for human reading. Its wording can change without notice, and a candidate with status: "no_match" may be described there as "partially aligned" — which sounds positive even though the profile was not retained.

For any automated processing, rely on status (match / no_match / na) and overall_score, whose contract is stable.

Recording consent

The payload contains a consent object indicating whether the candidate agreed to the call being recorded:

• valid: consent was required and the candidate accepted
• invalid: consent was required and the candidate declined
• not_collected: no consent step configured, or no explicit answer recorded

consent is null when no consent step is configured on the integration.

CV report statuses

• match: The CV matches the criteria (score >= matching threshold)
• no_match: The CV does not match the criteria (score < matching threshold)

Important behaviour

If the CV report returns no_match, the process stops automatically with status completed and no interview report is generated. This saves credits by avoiding calls to candidates who do not meet the basic criteria.

How Omogen works

Important notes

Data validation

• phone: accepts international (+33…) and national (06…) formats — normalised to E.164
• email: strict email format validation
• cv_filename (CV-only): accepted extensions .pdf, .doc, .docx, .txt, .rtf

Deployment modes

Mode	Description
single-call	One immediate call
sms-then-call	An SMS is sent, then a call 5 minutes later
sms-invitation	An SMS is sent with an invitation link for self-scheduling
email-invitation	An email is sent with an invitation link for self-scheduling
3-days	Attempts spread over 3 days
reactivation	Call → SMS (2 min) → Call (1 hour) → Call (next day, 1 pm)

Support and contact

Your API keys are generated self-serve when you create the integration. For any other question about the API:

• Email: gillian@omogen.ai