Every endpoint is under /v1, and /v1 stays. Fields and features are added to it over time; anything that would break a working integration is announced first, at least 30 days ahead.

Changes that ship at any time

These are additive. A client that ignores what it does not read keeps working through all of them:

• New fields in responses and in webhook payloads.
• New query parameters, and new values accepted by existing ones.
• New endpoints and new webhook event types.
• New values in fields whose vocabulary is open, such as benefits and industry.

Write your client to ignore unknown fields and to handle a value it has not seen before.

Breaking changes

A breaking change is one that can stop a working integration:

• removing or renaming a field, a query parameter or an endpoint;
• changing a field's type or format;
• changing what a parameter or a value means.

Each one is announced at least 30 days before it ships:

• in the changelog, under Deprecated, with the date it ships;
• by email to every account whose API keys called the affected endpoint in the previous 30 days;
• in the OpenAPI spec, where the field or endpoint is marked deprecated: true and carries its removal date in x-sunset.

Until that date, the old and the new form are both served, so you can switch at any point in the window.

A deprecated endpoint also answers with these headers until it is removed (example values):

Deprecation: @1793491200
Sunset: Tue, 15 Dec 2026 00:00:00 GMT
Link: <https://jobven.com/changelog>; rel="deprecation"

Deprecation is when it was deprecated, in Unix seconds (RFC 9745); Sunset is the date it stops being served (RFC 8594); Link points to the changelog entry.

Webhooks

Webhook payloads follow the same rules. Every delivery carries the payload version as a date, in the envelope's version field and the Jobven-Webhook-Version header. New fields keep the version; a breaking change to the payload gets a new date and the same 30 days' notice. See Versions.

Currently deprecated