Certification guidance
Automation and APIs
Public verification is already a separate anonymous API. Application submission and fleet automation have different authority and availability.
Which API is publicly available?
The existing public verification API supplies a bounded result and mirrorable signed inputs. It requires no applicant account. No public manufacturer application API or sandbox is offered by this guidance.
Why would an application client need separate authority?
Submitting private evidence or managing a robot is different from reading a public certificate. A machine client needs the applicable scoped authorization; public verification access grants no application, signing or account-management capability.
How should an interrupted client request be recovered?
Keep the original operation reference and read its durable outcome. An idempotent continuation returns the original work for the same request rather than duplicating it. A different key or repeated submission must not bypass an existing hold, change frozen evidence or mint a replacement certificate silently.
Does a successful batch response certify every item?
No. Transport success does not establish evaluation success, issuance or publication. The development contract keeps each item’s identity and outcome separate. Consumers must read the relevant item’s actual state.
Is an application status response proof of validity?
No. It reports workflow progress within its authenticated scope. Public certificate truth comes from admitted signed artifacts and their verification, independently of the application database.
Does an email or callback replace verification?
No. Notifications help a recipient find a recorded outcome. They do not replace the original artifact, an acceptance receipt or independent verification. A missing notification also does not prove that issuance failed.
Can automation or payment change an existing certificate?
Not through account or economic state. Automation may prepare and observe authorized work, but it does not acquire the certifier’s key. Changes to certificate reliance follow the applicable signed lifecycle process; balances, refunds and provider events cannot silently change that truth.