| name | certinext-api-bugs |
| description | Known CertiNext vendor API bugs affecting domain listing and filtering. Use when editing certinext/domains.py, dcv_update.py, or README.md sections about listing or filtering domains. |
The following CertiNext API bugs were confirmed by vendor support on 2026-05-20. Vendor will notify when fixed.
Broken parameters
domainStatus + dcvStatus filters together on GET /api/certinext/v2/domains
Originally returned HTTP 400 when both were used in one request (reported
2026-05-20). Probe R02 confirmed the combination now works in both
environments (2026-07-02, GitLab issue #6). Shipped in the 1.0 refactor
(phase 1, 2026-07-06): get_pending_dcv() now sends domainStatus=ACTIVE
server-side — it exactly matches the first conjunct of Domain.needs_dcv.
dcvStatus stays client-side deliberately: "needs DCV" means anything
other than VERIFIED, which the server can't express as a single filter
value — an allow-list filter would also silently drop unknown future
statuses. (dcvStatus=EXPIRED returning 400 is not part of this — see
Resolved below; it's expected behavior, not something to work around.)
Resolved
search on GET /api/certinext/v2/domains — GitLab issue #2,
closed. History: returned everything regardless of value until ~2026-05;
exact-FQDN fixed 2026-06-05; substring matching fixed in sandbox 2026-07-02;
confirmed fixed in production too 2026-07-08 (probe R01). search is
now reliable server-side for exact-FQDN and substring (LIKE) matching in
both environments. It's still substring-only, not regex — get_list()'s
pattern param stays for cases search can't express (alternation,
anchoring, wildcards); that's a deliberate feature now, not a workaround for
this bug.
dcvStatus/domainStatus enum discrepancies — GitLab issue #6,
closed 2026-07-10. Not vendor bugs: the Postman collection (hand-maintained)
had EXPIRED listed as a valid dcvStatus and DEACTIVATED as a valid
domainStatus — both wrong. Vendor confirmed the OpenAPI spec at
/v3/api-docs/certinext-v2 (generated from source, always matches the
running service) is canonical: dcvStatus is PENDING/VERIFIED/REJECTED
only, domainStatus is ACTIVE/INACTIVE/EXPIRED only. The 400s on
dcvStatus=EXPIRED and domainStatus=DEACTIVATED are correct, permanent
behavior — do not treat them as bugs to watch for a fix. DcvStatus/
DomainStatus in certinext/models/domains.py were tightened to match
(also dropped REVOKED from DomainStatus, which the spec never listed —
a discrepancy the vendor ticket didn't cover but the spec settles directly).
Whenever Postman and the OpenAPI spec disagree on this API going forward,
trust the OpenAPI spec.
Pagination
GET /api/certinext/v2/domains's default sort order (createdAt desc) is
not a documented stable total order across offset pages — vendor-confirmed;
looping raw offset/limit under it can skip or duplicate rows. domainName
is a documented, unique sortBy value, so DomainAccessor.get_list() pages
under sortBy=domainName&sortDir=asc whenever it's asked for the whole
account (no offset/limit given). Only pass offset/limit explicitly
when you want one raw server page and can tolerate the default ordering.
Filing a new issue
When a new bug is confirmed, create a GitLab issue and assign it to yourself unless it clearly belongs to another team:
$env:GITLAB_HOST = "gitlab.its.maine.edu"
glab issue create -R sysadmin/python-libs/certinext \
--title "CertiNext /endpoint: short description" \
--description "..." \
--label "certinext,vendor-bug" \
--assignee @me
Use --assignee @me by default. Assign to someone else only if the issue involves infrastructure, credentials, or a system owned by a different team.
When the vendor fixes these, update
README.md — update the "List domains needing DCV" section if the server ever gains a way to express "not VERIFIED" as a single dcvStatus filter value
