Skip to main content

Security

Warrant applications carry some of the most sensitive material an agency handles: clinical detail, allegations, addresses, and the identities of people who have not been charged with anything. This page describes what the API does to protect it, and what your integration has to do.

Keys​

An API key is a bearer credential. Whoever holds it can act as your integration against your agency.

  • Keep keys server-side. Never ship one in a browser, a mobile app, or anything a user can read.
  • Store them in a secrets manager, not in source control, environment files committed to a repository, or a wiki page.
  • Use one key per integration, so a compromise is contained and revocation does not take down unrelated systems.
  • Grant the narrowest scopes that work. Most integrations never need warrants:sign.
  • Rotate on a schedule, and immediately if a key may have been exposed: deploy the new key, then have the old one revoked.

Browser-direct calls are not a supported pattern. Put your own server between a user interface and this API.

Agency isolation​

Every key belongs to one agency and every query is confined to it. A resource in another agency returns 404, identical to one that does not exist, so the API never confirms what another agency holds.

Encryption​

Warrant contents, signatures, and the personal data inside them are encrypted at rest with per-agency keys, and decrypted only when returned to a caller entitled to read them. Everything is served over HTTPS; requests over plain HTTP are refused.

This is invisible to your integration: you send and receive ordinary JSON. What it means is that a copy of the underlying storage is not a copy of the warrants.

Attribution and access logging​

Two things are recorded on every call and neither is optional:

  • Writes require X-On-Behalf-Of, so the audit trail names the person, not just the integration.
  • Reads of a warrant document or an attachment are recorded as downloads, so an agency can answer who obtained a copy.

What your integration should do​

  • Log request_id, not payloads. Warrant form_data should not end up in your application logs, your error tracker, or a support ticket.
  • Mind download URLs. pdf_url and download_url are signed and short-lived. Do not store them, forward them, or put them in an email. Re-read the resource for a fresh one.
  • Be deliberate about public links. Publishing makes a warrant readable by anyone with the URL. Unpublish when the need has passed.
  • Deactivate promptly. When someone leaves, deactivate their membership; their history stays intact, and their ability to act ends.
  • Do not build your own cache of warrant contents unless you have to. If you must, encrypt it, restrict it, and give it a retention period.

Retention and deletion​

Trashing is reversible; permanent deletion is not, and it is limited to trashed applications and untrashed drafts (trash and restore). The audit trail survives deletion by design: the record that a warrant existed and who acted on it is what makes the trail worth having.

Signed warrants are usually court records with a statutory retention period. Check your jurisdiction's rules before automating any deletion.

Reporting a problem​

If you believe you have found a vulnerability, or that a key has been exposed, contact eCourtDate immediately with the request_id values involved and stop using the affected key. Do not test against another agency's data.