Skip to main content
The Jobo API changes additively, with no version in the URL. Build your client to accept new fields and values, and watch the changelog for the rare breaking change.

​
There’s no version in the path

Every route is /api/{resource}: /api/jobs, /api/jobs/feed, /api/companies/{id}. There is no /v1/ or /v2/ segment, and there never has been. Don’t build URLs that expect one. The OpenAPI document’s info.version is a date, currently 2026-08-31. It tracks the spec, so a new date does not mean an incompatible change.

​
The one exception: Auto Apply

Auto Apply is the only surface with an explicit contract version. Every Auto Apply and mailbox response, error bodies included, carries an api_version field, currently 2026-08-31. Auto Apply is coming soon, and you can build against the sandbox today. If the synchronous contract changes before launch, api_version is how you’ll tell.

​
The compatibility contract

Every breaking change is announced ahead of time in the changelog. A client that rejects an unrecognized field or source value will break as the API grows.

​
Writing a client that survives change

  • Deserialize permissively and ignore unknown fields. A new field on a job or company object must not raise an exception.
  • Don’t depend on field order. JSON key order is not part of the contract.
  • Branch on the status and the code field. When there is no code, match the error or title string. Never match detail or message, which are prose and may be reworded without notice. See Errors.
  • Treat source as an open set. Don’t hardcode an enum of valid values, and don’t reject jobs from a source you don’t recognize.
  • Pin the client library version in your dependency file and upgrade deliberately. See Client libraries.