HoundDog API Documentation

API changelog

Dates are deploy dates to production. Entries marked With the v2 launch shipped in the same deploy that made v2 available.

v2

  • With the v2 launch. API v2 is available at https://app.hounddog.com/api/v2/, alongside v1 and with the same API keys, documented on these pages and in the OpenAPI 3 document (browse it in Swagger UI). It covers:
    • Parties: list with lifecycle, status, external id, tag, requirement and name search filters and updated_since; detail with status, requirements, noncompliance reasons, expirations, contacts, tags, custom fields, per-project status, certificates, factor scores and the reachouts in progress; create and update; the actions archive, unarchive, pause, unpause, invalidate_certificates and send_reminder; contacts; a party's events. See Parties.
    • Certificates: list and detail with the parsed coverage data once a certificate is processed, upload in the request or through a direct upload, invalidate and restore, download; a party's insurance documents. See Certificates.
    • Approval overrides (create, update, revoke) and compliance requests (read).
    • Insurance requirements with one coverages map for every coverage type, and GET /coverage_types.
    • Multiple insurance requirements: a party and a project can each carry several requirements at once, all enforced together, served and written as insurance_requirement_ids.
    • Projects: create, update, delete, attach and detach parties, and the lifecycle actions.
    • Custom fields, written as a patch (only the fields you send change), and the field definitions themselves: list, create, change, archive and restore.
    • Compliance profiles.
    • Documents.
    • Events with filters and the since_id cursor, including Party Edited with the old and new value of every changed field, and webhook subscriptions with signed deliveries, test sends, secret rotation and a delivery log (see Webhooks).
    • The account's settings and its dashboard users.
    • Key scopes read and read_write (Authentication), one error shape with a request id (Errors), and collections in one envelope (Pagination).
    • Idempotency keys: every POST accepts an Idempotency-Key header, so a retried request is answered from the first one instead of running twice.
    • W-9s: list, read, request, upload and download a party's W-9s, with tax ID exposure controlled by an account setting and a per-key grant.
    • Document signing: read signing templates; create and send, resend, invalidate and download signing requests, and record a document signed outside HoundDog.
    • Requirement statuses: read-only, one row per party and requirement, with its status, expiration and the reasons behind it. These two endpoints are documented now and answer once requirement statuses are enabled; see their page.

Changes after the launch are listed here with the date they reach production.

v1 maintenance

  • Multiple insurance requirements. POST /api/v1/vendors/create accepts insurance_requirement_ids as well, and the vendor body and each of its projects carry it. v1 answers in its own vocabulary: an id that is not an insurance requirement of your account, insurance_requirement_id sent beside the list, an empty list, and the list on an account without the feature are each 400 Malformed Request, and a list the feature itself refuses (an individual's requirement on a vendor) is 422 with that message. v2 answers the same cases 422 validation_failed and 403 feature_disabled, as it does for every other field.
  • Multiple insurance requirements. The v1 vendor body, and each of its projects, now also carries insurance_requirement_ids. Without the feature it holds the one requirement insurance_requirement_id already reports, so nothing you read changes; a strict schema (additionalProperties: false) has to allow the new member.
  • With the v2 launch. Every response from a v1 endpoint carries Deprecation: @1798761600 (2027-01-01, RFC 9745's date form; v1 keeps working after it) and a Link header with rel="deprecation" pointing at Migrating from v1. Bodies and status codes are unchanged. No Sunset header is sent: no end date is set.
  • With the v2 launch. API keys have a scope. Every key created before v2 is read_write and works exactly as before; a key created with the read scope answers a v1 write (POST /api/v1/vendors/create, POST /api/v1/documents/create) with 403 and the body {"error":"This API key has the read scope and cannot make this request; it needs a read_write key"}.
  • Added 2026-10-19. GET /api/v1/events can list the new Party Edited event (see Events). Nothing else in v1 changes.
  • Added 2026-10-19. GET /api/v1/events can list the new custom field definition events (Custom Field Definition Created, Updated, Archived, Restored and Deleted; see Custom field events). Nothing else in v1 changes.
  • Changed 2026-10-19. A Project Edited event recorded from the dashboard's project form now names the custom fields the edit changed (. Custom fields changed: A, B), as one from the API does.
  • Changed 2026-10-19. A save on the dashboard's project form that changes nothing no longer records a Project Edited event, and attaching parties from the form records only its own event. GET /api/v1/events and webhook subscribers to Project Edited see these. Nothing else in v1 changes.
  • With the v2 launch. GET /api/v1/events can list the customer-visible event types added with v2, such as Certificate Processed.
  • 2026-10-08. Requests are counted against a per-key rate limit (300 requests per minute by default); see Rate limits. The Api-Key header is split at its first -, and spaces around the header value are ignored.
  • 2026-10-08. A request with no Api-Key header returns 401 instead of 500. A missing or malformed parameter returns 400 with Grape's message instead of 500. An unexpected server error returns 500 with the body {"error":"Internal Server Error"}. Deactivated accounts, and accounts whose API access is turned off, receive 403.
  • 2026-10-08. GET /api/v1/events returns only customer-visible events; GET /api/v1/events/:id returns the event (previously it answered 404 or, when the id happened to match a project, that project).
  • 2026-10-08. V1 documents are reachable at /api/v1/documents, /api/v1/documents/vendor/:id, /api/v1/documents/:id and POST /api/v1/documents/create (previously shadowed by the vendors resource).
  • 2026-10-08. The collect_compliance_on description now says it has no effect on its own in v1.