Account

Four read-mostly endpoints for the organisation behind your key. None of them touch students or assessments.

Keys

curl https://prep-api.experthire.cloud/v1/api-keys \
  -H "Authorization: Bearer $EH_SECRET_KEY"

Metadata only, for your key's own environment. The secret is stored as a one-way digest, so nothing can show it to you again after the call that minted it.

POST /v1/api-keys mints another key. The environment is never read from the body: it is the calling key's own, so a test key cannot mint a live one. That, rather than any role check, is what keeps this a lateral move instead of an escalation.

Rotation and revocation are covered in Authentication.

Branding

GET /v1/branding returns the organisation's public identity. PATCH /v1/branding takes name, communication_email and timezone, and nothing else.

logo_url, is_whitelabel and brand_inherit are read-only. The logo needs an upload flow this API does not expose, and the two flags arm provisioning.

timezone must be an IANA name such as Asia/Kolkata. An unparseable value is rejected rather than stored, because a bad one silently breaks every scheduled reminder you send.

Members

GET /v1/members lists the organisation's staff: administrators and mentors.

Students are deliberately absent. A prep organisation holds thousands of them, they are the subjects of the assessments you create rather than members of your account, and enumerating them here would hand you a roster you have no reason to hold.

Live keys only, for the same reason: these are real names and addresses with no sandbox equivalent.

There is no invite endpoint, and there will not be one. An invite grants console access, which is the one escalation a key rotation cannot undo.

Activity

GET /v1/analytics/activity counts your assessments by type and stage, so a cohort readout does not mean paginating every list. Both bounds are optional Unix seconds:

curl "https://prep-api.experthire.cloud/v1/analytics/activity?created_after=1767225600" \
  -H "Authorization: Bearer $EH_SECRET_KEY"

{
  "object": "activity",
  "from": 1767225600,
  "livemode": true,
  "interviews": {
    "total": 1284, "scheduled": 51, "in_progress": 3,
    "processing": 7, "completed": 1180, "cancelled": 43
  },
  "coding_tests": { "total": 402, "completed": 377 },
  "prompt_engineering": { "total": 118, "completed": 109 },
  "psychometric": { "total": 96, "completed": 91 },
  "resumes": { "total": 2210, "completed": 2166 }
}

Two things worth knowing before you reconcile these against your own numbers.

interviews excludes the separate product surfaces, which have their own counts in the same response. Adding interviews to the other four therefore never double-counts.

resumes.completed means carrying an analysis, which is deliberately not overall_score > 0. A resume can legitimately score zero and still have been scored.