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, client submissions, and declared experience (or profile_urls if you have no experience to send).

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. A single request may not exceed your concurrent run limit (10 by default), so larger batches are rejected with 422 and error batch-exceeds-concurrent-cap. Batching does not increase your daily allowance: the daily limit counts candidates, not requests, so 20 requests of 50 candidates consume the same budget as 1,000 single-candidate requests.

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 submissions, and experience unless you supply profile_urls. 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.

experienceOptional when profile_urls is supplied, otherwise required (max 40). Employment you already know about, used to distinguish new hires from previously known employers. Send an empty array when you have none and give us a profile URL instead.

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.

experienceRequired unless you send profile_urls. Each entry requires company. Include start_date and end_date where you have them: they let us tell a past stint at a client from a new one.

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).

Optional fieldsMay be omitted or sent as null. Both are treated as absent, so "end_date": null on a current role is accepted.

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 submissions, and either experience or profile_urls.

{
  "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" }
      ]
    }
  ]
}

Each service has its own per-partner run limit, and live and precompute calls share it: by default 1,000 runs per UTC day and 10 concurrent in-flight. Your account may be configured with a higher limit — contact us if you need one raised. Exceeding the concurrent limit returns 429 Too Many Requests with error precompute-cap-exceeded and a short Retry-After; retry after that delay. Exceeding the daily limit returns 429 with the same error and a Retry-After that runs until the next UTC midnight; stop sending until it resets rather than retrying in a loop. A batch larger than your concurrent limit is rejected with 422 and error batch-exceeds-concurrent-cap — send smaller batches or ask us to raise the limit.

Create response

A successful create returns 202 Accepted with status: pending. Batch precompute returns an items array. There is no cached 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",
        "confidence": "confirmed"
      }
    ]
  },
  "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, confidence.

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.

confidence tells you how much review a match needs. confirmed: strongly corroborated, the company names align closely, and the employment start date falls after your submission. likely: corroborated, but the match is to a parent or group company, or the identity was less certain. needs_review: weaker corroboration, no usable employment date, or lower identity confidence. Check a needs_review match yourself before acting on it.

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

bypass.matches[].confidenceconfirmed, likely, needs_review

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, submissions, or experience without profile_urls.

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. These are request-rate limits and are separate from the per-partner run limits described under Precompute.

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.
An employer already in your experience list is still reported, because you may have recorded it after the candidate joined. It is returned as needs_review unless the dates show they left and joined again after you submitted them, in which case it is scored normally. Only companies in your submissions list are ever reported.
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