Attestation

/certify — signed attestations for MotionSpec spec documents

A MotionSpec spec document describes the motion a page ships. /certify signs such a document so any holder of a MotionSpec key can later check that the exact spec you claim is the spec you were issued a signature for. It is evidence by reproduction: the signature covers the document, and the same document always yields the same compiled motion.

Status. The endpoint is live and key-bound. New keys are issued through the Dev Key plan, which checks out in your browser. Your key is shown once on the page right after checkout, and you can rotate it any time from your account page. Write to hello@motionspec.dev if anything goes wrong.

What it is — and what it is not

It is a signature over a MotionSpec spec document: what was submitted, by which key, at which time.
It is reproducible — the MIT compiler on npm turns the same spec into the same output on any machine, so a reader can re-derive the result instead of trusting us.
It is not an accessibility certificate. It says nothing about pages you did not compile through MotionSpec, and it does not claim conformance with WCAG, the EAA, the ADA or any other law.
It is not a scan of a live site. That is the free motion check and motion_audit; see the connector docs.

Where it runs

On the hosted MCP service, not on this website. Two routes, both POST, both key-bound:

POST https://api.motionspec.dev/certify          sign a spec document
POST https://api.motionspec.dev/certify/verify   check a signature

Authentication is the same single header as every other keyed route — treat the key like a password:

x-motionspec-key: <your key>

Example

curl -sS -X POST https://api.motionspec.dev/certify \
  -H "content-type: application/json" \
  -H "x-motionspec-key: <your key>" \
  -d '{"spec": { ... your MotionSpec spec document ... }}'

And to check a signature someone hands you:

curl -sS -X POST https://api.motionspec.dev/certify/verify \
  -H "content-type: application/json" \
  -H "x-motionspec-key: <your key>" \
  -d '{"attestation": { ... the attestation object /certify returned ... }, "signature": "<the signature>"}'

/certify answers {"attestation", "signature", "alg"}; /certify/verify takes exactly that attestation object back together with the signature and answers {"valid", "subject", "verdict"}. Sending the spec instead of the attestation returns 400 missing_fields.

Both routes are POST only and fail closed. Without a valid key they answer 401 {"error":"unauthorized"}; GET answers 404 (measured 18 Aug 2026). The keyless tools motion_catalog and motion_validate stay open and need no key at all.

Before you need a key

motion_validate checks a spec against the schema and is free and keyless — run it first, in the playground or from any MCP client. Signing only makes sense once the spec is the one you actually ship.

Scope, rate limits and what is stored are documented on /docs. Nothing you submit to the keyless tools is stored; for the keyed routes we record the tool name, a non-identifying key label, the plan tier, timestamp and outcome — never the spec contents. See the Privacy Policy.