Versioning
The API is versioned in the path:
https://api.warrants.ecourtdate.com/v1
/v1 is the current and only version. A change that would break a working
integration ships as a new version, not as a change to this one.
What will not change under /v1
- Endpoint paths, methods, and
operationIdvalues. - The meaning and type of an existing field.
- Existing values of an enumeration, such as the four workflow states.
- Error
codevalues and the shape of the error envelope. - The authentication model:
x-api-keyandX-On-Behalf-Of.
What can change at any time
These are additive and your client must tolerate them:
- New fields on responses. Ignore fields you do not recognize; never fail on an unexpected key.
- New optional request fields.
- New endpoints and new tags.
- New enumeration values. New audit actions and new file resource types appear as the product grows. Treat every enumeration as open and handle an unknown value without crashing.
- Reworded
messagetext in errors. Branch oncode. - New error codes, for conditions that previously fell under a broader code.
Deprecation
If something has to be withdrawn:
- It is announced in these guides and marked in the OpenAPI specification.
- Responses carry
Deprecationand, once a removal date is set,Sunsetheaders. - It keeps working for at least 12 months from the announcement.
Nothing is removed without that window, and security fixes are the only exception.
Tracking changes
The OpenAPI specification is published alongside these guides and is the machine-readable record of the current surface. Diff it between releases to see exactly what moved, or generate a client from it and let your compiler tell you.
Writing a client that ages well
- Read templates at runtime instead of hard-coding
form_datakeys. - Branch on
code, not onmessage, and not on HTTP status alone. - Treat enumerations as open sets.
- Ignore unknown response fields rather than rejecting the payload.
- Pin nothing to the order of a list unless the operation documents one.