Contents

Partner API

Bypass Monitor API Integration

Know when introductions get hired

Submit candidates you introduced to clients and detect when they appear at those companies, with evidence and timing analysis.

Request API Access

Best fit for

Staffing and recruitment agencies monitoring client submissions

RPO providers verifying introduction outcomes

ATS vendors adding bypass detection to agency workflows

Teams that submit candidates to multiple clients and need hire visibility

Partners who already track submission dates and client company names

Integration flow

Get approved and receive an API key

Request access from TieTalent. Once approved, you receive an X-API-Key for your integration.

Submit a bypass check

POST to /api/v1/bypass-checks with candidate identity anchors, declared experience, and client submissions.

Receive 202 Accepted

The response includes a check id, status: pending, and candidate_id. Bypass checks do not expose a cached flag on create. Always poll or wait for the webhook.

Poll or wait for a webhook

GET /api/v1/bypass-checks/{id} until status is completed or failed. Webhooks (bypass_check_ready / bypass_check_failed) are preferred when configured.

Act on bypass evidence

When bypass.detected is true, review bypass.matches for submitted company, found employer, match quality, and hire timing relative to your submission date.

Authentication

Send your partner API key in the X-API-Key header on every request, identical to Candidate Intelligence and Talent Update.

Request headers

X-API-Key: ats_your_api_key_here
Content-Type: application/json

Create bypass check

Creates an asynchronous bypass check. TieTalent runs a talent update internally, then compares discovered employers against your submission list.

Send complete submissions with submission dates whenever you have them; timing analysis depends on submitted_at.

POST/api/v1/bypass-checks

{
  "candidate": {
    "id": "cand-9911",
    "first_name": "Alex",
    "last_name": "Rivera",
    "work_email": "alex.rivera@example-corp.com",
    "employer_website": "example-corp.com",
    "role": "Software Engineer",
    "location": "London, UK",
    "profile_urls": [
      "https://linkedin.com/in/alex-rivera-example"
    ],
    "experience": [
      {
        "company": "Previous Corp",
        "role": "Engineer",
        "start_date": "2014-01",
        "end_date": "2016-01",
        "is_current": false
      }
    ],
    "submissions": [
      { "company": "Acme Client Ltd", "submitted_at": "2025-03" },
      { "company": "Beta Industries AG", "submitted_at": "2024-11" }
    ]
  }
}

Request fields

candidate (required object)

Includes all Talent Update identity fields plus required experience and submissions. See also the Talent Update request fields.

Identity combination (at least one)

Fields

Accuracy

A

work_email

Best single anchor.

B

first_name + last_name + (employer_website or company)

Good when you hold a name and employer.

C

employer_website + role

Useful when you know employer and title.

idYour identifier for the candidate. Echoed as candidate_id.

first_name, last_name, work_email, employer_website, company, role, location, profile_urlsSame rules as Talent Update.

experienceRequired. At least one entry (max 40). Employment you already know about, used to distinguish new hires from previously known employers.

submissionsRequired. At least one entry (max 100). Each submission: company (client you submitted to) and optional submitted_at (YYYY-MM or YYYY-MM-DD).

submissions[] object

companyClient company name as you recorded the submission. Required.

submitted_atWhen you submitted the candidate to this client. Used for timing analysis.

Optional top-level fields

mode"precompute" for background batch checks. See Precompute checks.

Not accepted

No CV or file upload. Identity anchors and structured submission metadata only.

Field rules

Validation failures return 422 with application/problem+json.

experienceMinimum one entry. Each requires company.

submissionsMinimum one entry. Each requires company. Maximum 100 per candidate.

submitted_atYYYY-MM or YYYY-MM-DD when provided.

work_emailCorporate domains only (same rules as Talent Update).

Precompute checks

Use POST /api/v1/bypass-checks with mode: "precompute" to warm checks in the background before a recruiter opens a submission record.

Batch precompute accepts up to 50 candidates per request via the candidates array. Live calls require a single candidate object. There is no force_refresh or create-time cache flag on bypass checks.

Batch precompute

Send mode: "precompute" with candidates instead of candidate. Each candidate must include experience and submissions.

{
  "mode": "precompute",
  "candidates": [
    {
      "id": "cand-9911",
      "first_name": "Alex",
      "last_name": "Rivera",
      "work_email": "alex.rivera@example-corp.com",
      "experience": [
        { "company": "Previous Corp", "is_current": false }
      ],
      "submissions": [
        { "company": "Acme Client Ltd", "submitted_at": "2025-03" }
      ]
    }
  ]
}

Precompute is capped per partner (1,000 runs per UTC day and 10 concurrent in-flight). Exceeding a cap returns 429 Too Many Requests with error precompute-cap-exceeded and Retry-After. Live runs are exempt from precompute caps.

Create response

A successful create returns <code>202 Accepted</code> with <code>status: pending</code>. Batch precompute returns an <code>items</code> array. There is no <code>cached</code> field on bypass create responses.

Single-candidate response

202

{
  "id": "bc_01JCXY",
  "status": "pending",
  "candidate_id": "cand-9911",
  "created_at": "2026-08-28T12:56:44.642Z"
}

Batch precompute response

Each item includes id, status: pending, candidate_id, and created_at.

202

{
  "items": [
    {
      "id": "bc_01JCXY",
      "status": "pending",
      "candidate_id": "cand-9911",
      "created_at": "2026-08-28T12:56:44.642Z"
    },
    {
      "id": "bc_01JCXZ",
      "status": "pending",
      "candidate_id": "cand-9912",
      "created_at": "2026-08-28T12:56:45.102Z"
    }
  ]
}

Get bypass check

Call GET /api/v1/bypass-checks/{id} to retrieve the check result.

status values

pendingCheck in progress (includes internal talent update).

completedCheck finished. bypass and optional talent_update are populated.

failedCheck failed. See error.

While status is pending

{
  "id": "bc_01JCXY",
  "status": "pending",
  "candidate_id": "cand-9911",
  "created_at": "2026-08-28T12:56:44.642Z",
  "completed_at": null,
  "bypass": {
    "detected": false,
    "matches": []
  },
  "talent_update": null,
  "error": null
}

When status is completed

{
  "id": "bc_01JCXY",
  "status": "completed",
  "candidate_id": "cand-9911",
  "created_at": "2026-08-28T12:56:44.642Z",
  "completed_at": "2026-08-28T12:58:12.441Z",
  "error": null,
  "bypass": {
    "detected": true,
    "matches": [
      {
        "submitted_company": "Acme Client Ltd",
        "found_company": "Acme Client Limited",
        "match_type": "variant",
        "submitted_at": "2025-03",
        "employment_start": "2025-04",
        "timing": "joined_after_submission"
      }
    ]
  },
  "talent_update": {
    "identity": {
      "confidence": "high",
      "full_name": "Alex Rivera",
      "headline": "Software Engineer at Acme Client Limited",
      "current_employer": "Acme Client Limited",
      "location": "London, UK"
    },
    "work_experience": [
      {
        "company": "Acme Client Limited",
        "role": "Software Engineer",
        "start_date": "2025-04",
        "end_date": null,
        "is_current": true,
        "confidence": "high"
      }
    ],
    "education": [],
    "online_presence": []
  }
}

Response fields

The response always includes a bypass object. When complete, a nested talent_update profile may also be present.

bypass.detectedtrue when at least one submission company matches a newly discovered employer.

bypass.matches[]Evidence rows: submitted_company, found_company, match_type, submitted_at, employment_start, timing.

talent_updateOptional nested profile (same shape as Talent Update) when identity resolution succeeded.

timing compares submission month to employment start month: joined_after_submission, already_employed, or not_determinable when dates are missing.

Enumerations

Enums may gain new members over time.

statuspending, completed, failed

bypass.matches[].match_typeexact, variant, group

bypass.matches[].timingjoined_after_submission, already_employed, not_determinable

Errors

Non-2xx responses use application/problem+json (RFC 9457).

Status

When

401

Missing or invalid API key.

404

Unknown check id or wrong partner.

422

Missing identity combination, experience, or submissions.

429

Rate limited or precompute cap exceeded.

500

Could not start or complete the check.

Example problem response

{
  "type": "https://intelligence.tietalent.com/errors/invalid-request",
  "title": "Unprocessable Entity",
  "status": 422,
  "detail": "Provide work_email, or first_name and last_name together with company or employer_website, or employer_website with role."
}

Rate limits & versioning

Rate limits

Same limits as Talent Update: per IP and per partner. 429 includes Retry-After.

Retry-After: 42

Versioning

Version is in the path (/v1). Additive fields may appear without a version bump.

Webhooks

At-least-once delivery. Handlers must be idempotent on event id. Treat GET /api/v1/bypass-checks/{id} as authoritative at all times.

Webhook endpoints are configured during partner onboarding.

Event types

bypass_check_readyBypass check finished successfully.

bypass_check_failedBypass check failed. Includes error_code in data.

Signature verification

Every delivery carries an X-CI-Signature header: t=<unix>,v1=<hmac-sha256> over "{t}.{raw_body}", HMAC-SHA256 with your whsec_... secret. Same scheme as Candidate Intelligence and Talent Update.

X-CI-Signature: t=<unix>,v1=<hmac-sha256>

# Signed over "{t}.{raw_body}". Reject timestamps older than five minutes.

Payload includes result_url, bypass_check_id, and candidate_id. Fetch full results via authed GET.

api_environment mirrors the label of the API key that authenticated the run (Production, Staging, or Test).

bypass_check_ready

{
  "id": "evt_01JDABC",
  "type": "bypass_check_ready",
  "created_at": "2026-08-28T12:58:12.441Z",
  "api_environment": "Production",
  "data": {
    "candidate_id": "cand-9911",
    "status": "completed",
    "result_url": "https://intelligence.tietalent.com/api/v1/bypass-checks/bc_01JCXY",
    "bypass_check_id": "bc_01JCXY"
  }
}

bypass_check_failed

{
  "id": "evt_01JDABD",
  "type": "bypass_check_failed",
  "created_at": "2026-08-28T12:58:15.441Z",
  "api_environment": "Production",
  "data": {
    "candidate_id": "cand-9911",
    "status": "failed",
    "result_url": "https://intelligence.tietalent.com/api/v1/bypass-checks/bc_01JCXY",
    "bypass_check_id": "bc_01JCXY",
    "error_code": "internal_error"
  }
}

Known limits

Understanding these limits sets correct expectations.

Company matching uses fuzzy name resolution; match_type indicates match quality.
When submitted_at or employment start is missing, timing is not_determinable.
Employers already in your experience list are excluded from bypass detection.
A check with bypass.detected: false means no new employer matched a submission, not proof the candidate was not hired.
Maximum 100 submissions and 40 experience entries per candidate; 50 candidates per batch precompute.

Partner Program

Start integrating Bypass Monitor

Request access and we will activate your partner API credentials for bypass monitoring.

Request API Access Contact Partnerships