Reference

POST /public/v1/consent

Record a PECR cookie-banner consent snapshot from a marketing site's cookie banner. Fail-open, unauthenticated, and distinct from credit-application consent.

2 min read

POSTHTTP method

NoneAuth

publicRing

Endpoint

Method	`POST`
Path	`/public/v1/consent`
Ring	public (unauthenticated write)

Parameters

A JSON body with the visitor's cookie-consent choices (analytics and marketing booleans) captured by the site's cookie banner. This is PECR §6 / GDPR cookie consent — not credit-application consent, which lives elsewhere.

Response

A JSON acknowledgement that the consent snapshot was recorded. The endpoint is fail-open — it never blocks the visitor on a storage failure, so the cookie-banner UX is never held up by the hub. It validates nothing about the caller's identity; it simply records the choice. Callers typically reach it over an HMAC-signed hop, but the endpoint itself is in the public ring and requires no auth.

Errors

The endpoint is deliberately forgiving; a storage failure returns a soft acknowledgement rather than an error so the banner UX is preserved. A 429 applies on rate-limit.

Frequently asked questions

Is cookie consent the same as application consent?

No. This endpoint records PECR/GDPR cookie-banner consent (analytics and marketing booleans). Consent given inside a credit application is captured on a different, authenticated path — do not conflate the two.

Why is it fail-open?

So a transient storage fault never blocks the visitor's cookie-banner interaction. The UX must not depend on the hub being up, so a failure returns a soft acknowledgement rather than an error.