---
title: "Create user job permission"
method: POST
path: "/v3/user_job_permissions"
tags: ["User Job Permissions"]
---

# Create user job permission

`POST /v3/user_job_permissions`

Grant a user a Job Admin role on a single job. The `role_id` must reference a Job Admin role; site admin and deprecated role types are rejected. Site admins already have access to every non-confidential job, so creating a user job permission for a site admin is a no-op and returns `204 No Content` instead of `201 Created`. To grant a role on jobs that don't exist yet, use `/v3/future_job_permissions` with an office and/or department scope instead.

## Request body

- object
  - `job_id` integer, required — Id of the job to grant access to. Must reference a job in the caller's organization.
  - `user_id` integer, required — Id of the user who should receive the role on this job. Must reference a user in the caller's organization. If the user is a site admin, the request returns `204 No Content` and no permission row is created — site admins already have access to every non-confidential job.
  - `role_id` integer, required — Id of the Job Admin role to grant on this job. Must reference a `user_role` with `role_type: job_admin`; site admin and deprecated role types are rejected.

## Response `201`

Successful

- object
  - `id` integer
  - `created_at` string, date-time
  - `updated_at` string, date-time
  - `job_id` integer — Id of the job this permission grants the user access to. References a `/v3/jobs` row.
  - `user_id` integer — Id of the user receiving access to the job. References a `/v3/users` row. Site admins are never represented here — they have implicit access to every non-confidential job — so a user with a site admin role will not appear in this list.
  - `role_id` integer — Id of the Job Admin role the user holds on this job. References a `/v3/user_roles` row; only roles with `role_type: job_admin` can be granted through this resource.
  - `automated` boolean, nullable — When `true`, the permission was created by an automated permission rule (e.g. a `future_job_permission` that matched the job when it was opened, or an automated permission policy) rather than assigned by hand.

## Other responses

- `204` — Successful (No Content)
- `401` — Unauthorized
- `403` — Forbidden
- `422` — Unprocessable Content

---

[API](https://skmtc.dev/greenhouse/apis/auth-api.md) · [All operations](https://skmtc.dev/greenhouse/apis/auth-api/llms.txt) · [OpenAPI document](https://skmtc-service-production.skmtc.workers.dev/v1/apis/greenhouse/auth-api/revisions/9517a2e54640/schema)